[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



why?

On Wed, Jun 11, 2008 at 10:27 PM, Charlie Nolan <funnyman3595@xxxxxxxxx> wrote:
> No, you should not be able to release a lock that you don't have.  The
> threading module sets precedent, if nothing else:
>
>>>> import threading
>>>> threading.Lock().release()
> Traceback (most recent call last):
>  File "<stdin>", line 1, in ?
> thread.error: release unlocked lock
>
> RLock is even stricter, it requires that you be in the same thread
> that acquired the lock, which is analogous to our situation.
>
> -FM
>
> On 6/11/08, Marcus von Appen <mva@xxxxxxxxxxxx> wrote:
>> On, Wed Jun 11, 2008, Charlie Nolan wrote:
>>
>>> Errors should never pass silently.
>>> Unless explicitly silenced.
>>
>> It is - at least for me - no error, if I try to unlock a surface that a)
>> has no locks or b) is locked by something else. Instead I'd vote for a
>> return value, which indicates whether the unlock() call was successful
>> or not.
>>
>>   if surface.unlock ():
>>       print "Unlock successful"
>>   ...
>>
>> This let's us preserve backwards compatibility while letting the user
>> check for success through the return value without the need to write
>> extensive try: except: statements.
>>
>> Regards
>> Marcus
>>
>