[bug #25307] [NSConditionLock tryLockWhenCondition:] shouldn't throw exception when lock is unavailable

[Richard Frith-Macdonald]

Follow-up Comment #14, bug #25307 (project gnustep):

I put the tests in the testsuite, ran it on MacOS-X, and checked the results,
then changed the case of NSConditionLock-tryLock in GNUstpe to match the
behavior in MacOS-X.

I noticed the comments about MacOS-X deadlocking for NSConnectonLock
attempting to lock recursively.  That was already flagged in the testsuite for
NSLock as a MacOS-X bug.
However, when I consider it, I don't think the MacOS-X behavior is totally
stupid  ... perhaps we should mimic MacOS-X and halt the thread in this
situation rather than raising an exception.   Does it make sense to allow an
application to deadlock a thread and (perhaps) have other threads continue
working?

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?25307>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/