Re: Deadlock in NSLog

[Nicola Pero]

> >
> On FreeBSD, libobjc has always used POSIX threads.  The abstraction  
> layer includes Mach, Irix, and Solaris back ends.  All of these  
> platforms now have a POSIX-compliant threading library (and have got  
> about a decade).  There are no platforms on which GNUstep runs that  
> do no either support POSIX threads or get POSIX threads through the  
> same POSIX-compatibility framework needed for the rest of GNUstep.
>
> This is one of the reasons why the new runtime uses pthreads  
> directly.  The abstraction layer in the GNU runtime is almost as big  
> as the entire codebase for the new runtime.

Possibly ... but the threading layer is all implemented and very  
stable and actively used - and provides nice flexibility in porting
the Objective-C runtime to different machines.  Any special reason for  
removing this flexibility and future-proofing - other than
that you might have found a bug in the code ?

Btw, when you compile the GNU Objective-C runtime as part of GCC, it  
automatically uses GCC's own internal abstraction layer for threads.
In that case, the abstraction layer is a single trivial file that just  
remaps all functions to GCC's own internal abstraction layer ones. ;-)

If you compile the GNU Objective-C runtime standalone, yes you do get  
a bunch of different threading implementations; I think the two
that are more likely to be in use are the posix one and the win32  
one.  If we removed the abstraction layer, how would we deal with
the win32 one ?  It's nice to be able to use native Windows threads on  
Windows.  Were you thinking of using some posix-layer on top
of the win32 threads ?

Anyway, my favourite reason for having the abstraction layer is the  
ability to disable threads on a platform without changing any
of the frameworks.  If you configure the abstraction layer to use thr- 
single, you can then compile and use everything on top of it
in single-thread mode with no threading library installed.  It also  
sounds quite useful if someone is porting Objective-C stuff to
some future architecture or machine where threads are not available,  
or there is no threading library - or they just want to get
stuff working single-threaded first and deal with thread complications  
later. :-)

Anyway given that the abstraction layer is all done for the most  
useful thread implementations (single, posix and win32) I'm not sure why
we'd want to remove it. ;-)

Thanks