I assume you are saying surface.unlock should throw an exception as opposed to do nothing in the cases where it's not valid? (if so, I agree)
Or was there some other condition you were thinking of as well? On Tue, Jun 10, 2008 at 3:23 PM, Charlie Nolan <[EMAIL PROTECTED]> wrote: > 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 > > >
