On 2005-10-17 19:56:19 +0000 Morgan Giddings <[EMAIL PROTECTED]> 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?
_______________________________________________
Bug-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gnustep
