Re: [Gnustep-cvs] r29472 - /libs/base/trunk/Source/NSLock.m

[Jonathan Gillaspie]

Fred:

No, I agree -- this type of change should go in the Change Log.  I'll update it 
accordingly.



--
Jonathan Gillaspie
address@hidden




On Feb 4, 2010, at 1:19 AM, Fred Kiefer wrote:

> This in itself is a great change, but do we really want to give up
> having ChangeLog entries for something as important as this?
> 
> Just a few days ago I was trying to find out where the file
> objc-gnu2next.h went and why it was removed. Of course I could dig
> through the history of the Source directory or more easily start a
> search on the mail folder where I keep all the change mails from SVN.
> But looking into the ChangeLog is so much simpler. I know some of you
> don't like this extra work, but these could just set up an automatism to
> have ChangeLog entries generated for them. And us others should try to
> have a bit more self discipline and not forget about these entries.
> 
> Fred
> 
> Am 03.02.2010 22:15, schrieb Jonathan Gillaspie:
>> Author: jonathanosx
>> Date: Wed Feb  3 22:15:03 2010
>> New Revision: 29472
>> 
>> URL: http://svn.gna.org/viewcvs/gnustep?rev=29472&view=rev
>> Log:
>> Fix several problems with lockWhenCondition:beforeDate:
>> First -- it needs to use timeIntervalSince1970 to be using the same 
>> reference date required for pthread_cond_timedwait
>> Second -- lockWhenCondition needs to loop because pthread_cond_timedwait can 
>> return prior to delay expiring (but with the wrong condition).
>> Third -- Internally the lock was incorrectly being unlocked on a delayed 
>> acquire (and YES return).  And was incorrectly being unlocked a second time 
>> when the timeout expired.
>> 
>> Also, fixed a problem with tryLockWhenCondition:
>> By calling lockWhenCondition: it would incorrectly report a deadlock (rather 
>> than just return no) when we already have the lock.
>> 
>> All these changes are in line with expected and documented behavior for 
>> NSLock.
>> 
>> Modified:
>>    libs/base/trunk/Source/NSLock.m