Re: Deadlock in NSLog

[David Ayers]

Am Montag, den 04.08.2008, 12:56 +0100 schrieb David Chisnall:

> 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.

That assumes that ObjC code using GNUstep also does not use the libobjc
API directly for certain features that OpenStep/Cocoa did/does not
export.  I don't believe that is a safe assumption.  In fact I would be
very surprised if code that uses threading in meaingfull ways does not
rely on some of those features.

> 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.  

If this wrapper is broken, then please file a bug (or even fix it since
this seems to be the pthread implementation which you are refering
to).  

> Quite how this makes more sense than using a  
> recursive pthread mutex is beyond me.  

Because libobjc wraps the threading API for a reason.  I don't claim to
know all the reasons.  I'm weary of ignoring them since debugging those
issues is painful.  So if libpthread (note I'm not stating POSIX... but
a specific implementation that -base would link to).

> 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.

I cannot asses that evaluation, but I do clearly see a benifit in fixing
libobjc rather than working around this in -base.  If those
pthread-compatibility libraries are so much better, then libobjc should
be using them.  I have no issue with that.  In fact I think it would be
great if libobjc could be simplified in this fasion.

> 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.

Well, there is a lot of code in -base that you would have adapt to
remove the dependency of libobjc's threading implementation.  In fact
I'm not even sure if the NSWillBecomeMutlithread hook can reliably be
called via the libobjc runtime if -base was configured with a different
threading library than libobjc.  (Of course it would happen to work if
the threading libraries happend to be identical).

But maybe you can explain why you do not seem to see an merit in fixing
the libobjc wrapper.

Cheers,
David