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

["Charlie Nolan" <funnyman3595@xxxxxxxxx>]

Modify it to print a warning to stderr and then go ahead for 1.8.1,
then throw an error in 1.9?

-FM

On 6/10/08, René Dudfield <renesd@xxxxxxxxx> wrote:
> 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
>>>> >
>>>>
>>>
>>
>