Re: Please test new NSLock implementation!

[Fred Kiefer]

This is not really a bug, but the new lock code exposes the use of
pthread.h in the header file NSLock.h. I would prefer to see this
reverted back, like the old code did it, using macros in the .m file to
convert the mutex and condition to the correct type.
It looks like you changed this on purpose. Do you have any specific
reason of handling this differently? I think it is better to keep
implementation details as the usage of a specific thread implementation
local to GNUstep, this would also make it a lot easier to provide
different implementations in the .m file, if we ever need it. But the
biggest benefit surely is that we keep user code free of our own
dependencies.

Fred

PS: There is a semicolon after the broadcast method in the .m file, this
may cause problems with the documentation generation.

PPS: Shouldn't NSConditionLock unlock twice in unlockWithCondition: as
the old code did?

David Chisnall schrieb:
> Hi Everyone,
> 
> I've just committed a new version of all of the NSLock family of classes
> to GNUstep-base, and a slightly reworked NSThread.  Bugs in this code
> have the potential to break any multithreaded applications, so please
> test them on your favourite platform, with your favourite applications. 
> And on platforms you hate with apps you can't stand, for that matter.
> 
> As a result of this change, GNUstep now depends directly on POSIX
> threads.  If you are building on Windows, you will need to download the
> pthread-win32 package from here:
> 
> http://sourceware.org/pthreads-win32/
> 
> I apologise for this extra dependency for Windows users, but it's
> probably better than the existing implementation which called this
> function to create a condition lock:
> 
> /* Allocate a condition. */
> int
> __objc_condition_allocate(objc_condition_t condition)
> {
>   /* Unimplemented. */
>   return -1;
> }
> 
> On most other *NIX systems you should have pthreads available by
> default.  I don't know if anyone's building GNUstep in the Symbian or
> QNX POSIX layer (let me know if you are), but pthread implementations
> are available here too.  The MIT Pthreads package provides a pure
> userspace (N:1) implementation of pthreads on almost any UNIX-like
> system, so should work for people using ancient UNIX (the pthread
> specification was released in 1996 and is supported on most UNIX systems
> that are less than a decade old; some of the more obscure corners are
> not well-supported, but we're not using any of those).
>