Re: NSLock behavior

[Richard Frith-Macdonald]

On 2005-10-17 19:56:19 +0000 Morgan Giddings <giddings@unc.edu> wrote:

> I am not sure whether this is a bug, or a difference in  interpretation of 
> the OpenStep spec... I apologize if this has been  discussed before.
>
> In Cocoa Foundation, if I have an NSLock that has not already been  locked, 
> and I do:
>
> [myLock unlock]
>
> it is ignored, and the program continues.
>
> In GNUStep, the same thing (trying unlock on something that has not  been 
> locked), it causes an exception.  This is because in the GNUStep 
> implementation, if objc_mutex_unlock returns -1, the exception is  raised. 
> Is this necessary?
>
> I wouldn't ask about this, except that working around the difference  in 
> the 
> code I'm porting is not entirely trivial....

I don't think the OpenStep specification actually says what -unlock should 
do in the case where a lock can't be unlocked ... so I'd call it a 
difference in the implementation rather than interpretation.

Normally, I'd say we should change the GNUstep implementation to match that 
of MacOS-X, however my feeling in this case is that maybe we shouldn't.  You 
have to ask yourself ... why should code be attempting to unlock  something 
that it hasn't locked?  Generally the unbalanced use of locks indicates a 
severe bug in a program ... so raising an exception  when locks are misused 
seems like a better idea than letting it pass.  Is the 'better' behavior of 
GNUstep sufficient to outweigh the implementation differewnce from MacOS-X?

What do other people think?