bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSLock behavior


From: Richard Frith-Macdonald
Subject: Re: NSLock behavior
Date: Tue, 18 Oct 2005 07:05:19 +0000

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?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]