Re: Deadlock in NSLog

[David Ayers]

Am Montag, den 04.08.2008, 14:00 +0100 schrieb David Chisnall:
> On 4 Aug 2008, at 13:29, David Ayers wrote:
> 

> I've come across a lot of code in Objective-C applications that uses  
> POSIX thread calls directly (this is even what Apple's Cocoa docs  
> recommend if NSThread and friends are not adequate for your  
> purposes)

You are aware that Apple can do this since it only supports libpthread
for it's runtime.

> , but none that calls GNU runtime threading functions other  
> than GNUstep.  Note that these are GNU runtime specific - the NeXT,  
> Apple, and Étoilé runtimes all use POSIX threads directly.  I am not  
> sure what happens with NSLock if you try to compile it with the NeXT/ 
> Apple runtime.  Possibly it just doesn't work.  It will need  
> rewriting before it can support the Étoilé runtime (and, thus, much  
> of Objective-C 2) anyway.

AFAIK the apple-gnu-* combos are not supported.

> >> 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).
> 
> The wrapper works in the specific usage patterns for libobjc.  It is  
> not a general wrapper.

OK... so this is the real topic...

Is the threading API of libobjc a publicly exported user interface or an
internal libobjc API?

> It wraps threading APIs because it is old, and when it was written  
> there was a Solaris threading API, an HPUX threading API, and IRIX  
> threading API, but no standard threading API.
> 
> It continues to wrap it because it, like GCC, supports non-POSIX  
> platforms such as Windows, OS/2, and VxWorks where POSIX is not a  
> native API.

[I'll refrain from replying to this for now as the answer to the above
question is what will define everything that follows.]

> >> 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.
> 
> For libobjc to use them would introduce a dependency on POSIX into  
> libobjc.  You can use libobjc and GCC to compile Objective-C code  
> that does not use GNUstep and that uses the platform APIs directly.   
> Adding a dependency on POSIX would be counter to the goals of GNU  
> libobjc.

I don't understand how this would be adding a new dependency... libobjc
already depends on libpthread /if/ it was configured to use libpthread.
Since all you care about is libpthread, all you need to fix it for is
libpthread and have all others use the historic code.  Of course a FIXME
would be nice.

> > 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).
> 
> NSWillBecomeMultithreaded should not be depended upon in any case.   

Well that's part of the point of discussion mentioned above.  Currently
we rely on:

 objc_set_thread_callback
 objc_thread_set_data
 objc_thread_get_data

Would you consider this part of the public ObjC API?  Do you see them
usefull for something other than a public API?  (I'm not trying to sound
sarcastic... I really wonder why you don't believe they were intended
for something internal.)

> Recent versions of Cocoa always run in multithreaded mode due to  
> difficulties in safely handling the notification and of  
> interoperating with code that uses pthreads directly (which Apple  
> have been encouraging for a while, although less so with the NSThread  
> extensions in 10.5).

I'm not sure how this is relevant.

> On OS X, NSWillBecomeMultithreaded is delivered if, and only if, new  
> threads are created with NSThread.  It is the responsibility of  
> NSThread to send this notification, and has nothing at all to do with  
> whether the thread APIs are called via a wrapper or not (I believe  
> early versions of OS X used Mach locks rather than POSIX ones (which  
> were slightly slower) but this doesn't matter unless you expect to be  
> able to lock a mutex with pthread_mutex_lock and unlock it with - 
> [NSLock unlock], which neither Cocoa nor GNUstep support).

It is true that NSWillBecomeMultithreaded is only intended for the
OpenStep/Cocoa API.  But what I was trying to say is that if the runtime
has been linked to a different threading library then -base that the
reliability of that notification is questionable.

> > But maybe you can explain why you do not seem to see an merit in  
> > fixing
> > the libobjc wrapper.
> 
> Because it is not broken as used by libobjc.  It was never intended  
> as a general-purpose threading abstraction layer, just as one that  
> allowed the specific use cases required by libobjc.  Fixing it in the  
> general case would require a lot of work which has already been done  
> operating system / libc maintainers.

OK... so let's center around "It was never intended as a general-purpose
threading abstracont layers" as this is where we disagree.  I believe
the threading API is exactly that:

A general-purpose threading abstraction layer for libobjc

If I am wrong and that is not the case, then I totally agree with you,
that GNUstep has no business whatsoever using any of the API.

Cheers,
David