Re: NSLock behavior

[David Ayers]

Richard Frith-Macdonald schrieb:
> 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?

I think this issue is in principle akin to relying on certain behavior
of gcc extensions...

I agree that we are free to raise an exception, yet I also know that
when porting large projects of legacy code, small differences in
undocumented behavior can cause quite a bit overhead (sometimes to the
point that the port is abandoned).  OTOH, I believe that an exception is
a lot easier to deal with when debugging than an NSLog. (I sometimes
hack -base to raise in cases where we currently only log warnings when
debugging.)

I'm still leaning toward an exception even though I can imagine some
default which can turn "pedantic exceptions" into NSLogs.  But I can
imagine that differentiating between "pedantic exception" and "useful
even if pedantic exceptions are turned off" can be cause for future
debates...

Also, I'm not sure that this would necessarily be worth the trouble as
exceptions are only one way our implementation differences can cause
portability issues.  I just wanted to mention the possibility.

Cheers,
David