Revrt (temporarily?) inconsistent change in locking behavior.

git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/base/trunk@27618 72102866-910b-0410-8b05-ffd578937521

ChangeLog

@@ -1,3 +1,16 @@
+2009-01-17  Richard Frith-Macdonald <rfm@gnu.org>
+
+	* Source/NSLock.m: Revert last change.
+	The Cocoa documentation actually says nothing about exceptions either
+	way.  I recall there was some discussion about lock behavior a few
+	years ago, which concluded that the GNUstep behavior was the best
+	available ... it returns NO if the lock is unavailable, but raises an
+	exception if you try to lock the lock twice from the same thread,
+	since locking twice from the same thread is almost guaranteed to be
+	a programming error.
+	If we want to remove this check, we need to do it consistently for
+	all locks and document the new behavior.
+
 2009-01-16 17:26-EST Gregory John Casamento <greg_casamento@yahoo.com>
 
 	* Source/NSLock.m: Correction for bug #25307.  According to Cocoa

Source/NSLock.m

@@ -447,6 +447,8 @@ NSString *NSRecursiveLockException = @"NSRecursiveLockException";
 
 - (BOOL) tryLock
 {
+  CHECK_RECURSIVE_CONDITION_LOCK(_MUTEX);
+
   // Ask the runtime to acquire a lock on the mutex
   if (objc_mutex_trylock(_MUTEX) == -1)
     return NO;