« Return to Thread: Deadlock in NSLog

Re: Deadlock in NSLog

by Nicola Pero-4 :: Rate this Message:

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

_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev

« Return to Thread: Deadlock in NSLog