On 6/10/08, Marcus von Appen <
mva@xxxxxxxxxxxx> wrote:
> Hi,
>
> regarding Jake's unlock() report I changed the locking behaviour to be
> more strict about who can unlock a locked surface.
>
> While it was possible to completely unlock a surface at any time from
> anywhere, it is now strongly tied to the object, which caused the lock.
>
> While it was possible to do stuff like
>
> subsurface = surface.subsurface (...)
> subsurface.lock ()
> surface.unlock ()
> # surface is unlocked again although subsurface is locked
> ...
> sfarray = pygame.surfarray.pixels3d(surface)
> surface.unlock ()
> # Monsters live here
> ...
>
> you now have to explicitly release the lock using the object that caused
> it:
>
> subsurface = surface.subsurface (...)
> subsurface.unlock ()
> surface.unlock () # No effect
> subsurface.unlock () # Now the lock is released.
> # surface is unlocked again
> ...
> sfarray = pygame.surfarray.pixels3d(surface)
> surface.unlock () # Nothing happens
> del sfarray # Surface will be unlocked
> # Rainbowland's coming!
> ...
>
> The surface.get_locked() method was adjusted accordingly and works as
> supposed now. Additionally the surface got a new get_locks() method,
> which returns a tuple with the object holding a lock. Though this is not
> always exact or very helpful, it can give you a quick overview about the
> reason for a dangling lock (numpy surfarrays for example are not listed,
> but a surface buffer instead as that one caused the lock).
>
> As this is tightly bound to reference counts, weakref pointers and other
> big sources for errors, I beg anyone to test it extensively with your
> code.
>
> Attached you'll find the patch, which hopefully brings love, joy,
> happiness and less errors to pygame.
>
> Regards
> Marcus
>