Re: [pygame] [PLEASE TEST]: New locking code

["Charlie Nolan" <funnyman3595@xxxxxxxxx>]

That was the point, yes.  Silently failing is a Bad Idea.

-FM

On 6/10/08, Brian Fisher <brian@xxxxxxxxxxxxxxxxxxx> wrote:
> 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 <funnyman3595@xxxxxxxxx>
> wrote:
>
>> Errors should never pass silently.
>> Unless explicitly silenced.
>>
>> -FM
>>
>> 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
>> >
>>
>