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

["René Dudfield" <renesd@xxxxxxxxx>]

Also note that we *need* to retain compatibility with existing code -
at least for pygame 1.8.1.  We shouldn't break existing code.


On Wed, Jun 11, 2008 at 8:45 AM, Charlie Nolan <funnyman3595@xxxxxxxxx> wrote:
> 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
>>> >
>>>
>>
>