Errors should never pass silently. Unless explicitly silenced. -FM
On 6/10/08, Marcus von Appen <[EMAIL PROTECTED]> 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 >
