[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSLock behavior
From: |
David Ayers |
Subject: |
Re: NSLock behavior |
Date: |
Tue, 18 Oct 2005 22:43:38 +0200 |
User-agent: |
Mozilla Thunderbird 1.0.2 (X11/20050817) |
Adam Fedor schrieb:
> On 2005-10-18 01:05:19 -0600 Richard Frith-Macdonald
> <richard@brainstorm.co.uk> wrote:
>
>>
>> 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 wonder where you would get into a situation where you didn't know if a
> lock had been applied or not? Apparently that may be the case here....
>
> Perhaps we could add an -isLocked method to check this?
>
That would add an API that would be kind of hard to emulate on Cocoa in
GSCategories (ie. for -baseadd). (Even though I ran into situtations
where I thought this would be handy.)
Cheers,
David