Re: Deadlock in NSLog

[David Chisnall]

On 4 Aug 2008, at 12:46, David Ayers wrote:

> Just to make my position clear.  I personally have no issue if libobjc
> required a working POSIX threads implementation and the legacy  
> threading
> support is removed from libobjc [in fact it may already have been
> deactivated].  But I do believe this should be fixed in libobjc and  
> not
> worked around in -base.
>
> Wether specific platform supports POSIX threads or not is irrelevent
> (and I seem to be misremebering the FreeBSD case, maybe it was NetBSD
> and pth?).  What is relevent is which specific threading library  
> libobjc
> was configured to use when it was built.  This decission is not
> something that GNUstep code can influence (well save if you have
> multiple libobjc's installed each configured differently).
>
> What you are proposing is to simply assume that libobjc was configured
> with a library called libptheads and have -base link against it  
> directly
> [something which have assumed in the past and possibly still assume in
> some cases since I haven't checked recently].  Yet this is error prone
> in the sense that it will work in most cases and fail subtly on some
> platforms by potentially linking two threading libraries.
>
> I also have no issue if there where some configure option as a stop- 
> gap
> until the fixed libobjc is widely distributed.  But never the  
> less... it
> should be fixed in "mainline" libobjc first.

I don't care whether libobjc uses its own threading implementation or  
not, however there is no reason for GNUstep to be using an  
inefficient and potentially (in this case, definitely) buggy wrapper  
around pthreads, rather than using pthreads directly.  The threading  
abstraction in libobjc implements the minimal functionality required  
for libobjc, not the minimal functionality required in general, or  
required for GNUstep.

NSRecursiveLock is implemented on top of objc_mutex, which emulates a  
recursive mutex on top of a non-recursive pthread (or other platform- 
specific) mutex.  Quite how this makes more sense than using a  
recursive pthread mutex is beyond me.  On platforms without native  
pthreads support, there are pthread-compatibility libraries that are  
a lot better tested for general-purpose use than the libobjc code.

libobjc has to support more platforms than GNUstep.  For example, it  
supports VxWorks and Windows directly.  In order to use GNUstep on  
these platforms, you need a POSIX API layer, such as cygwin or mingw,  
which implements its own pthread wrapper.  If you do this, then some  
code will be using the cygwin / mingw / whatever wrapper code around  
the native APIs, and some will be using the libobjc wrapper around  
the native APIs.

Since GNUstep depends on POSIX for a lot of -base, I see no reason  
why it can't use POSIX functions.

David