Re: Deadlock in NSLog

[David Ayers]

Am Montag, den 04.08.2008, 10:58 +0100 schrieb David Chisnall:
> On 4 Aug 2008, at 10:12, David Ayers wrote:
> 
> > Am Freitag, den 01.08.2008, 12:06 +0100 schrieb David Chisnall:
> >> It appears that GNUstep is using the ObjC runtime mutex, which tries
> >> to emulate a recursive mutex using a non-recursive mutex.  It looked
> >> like there was a potential for deadlock in here when I looked at the
> >> code a few months ago.  Since GNUstep depends on pthreads anyway, it
> >> might be better to use the pthread functions directly, rather than
> >> going through a buggy abstraction layer.
> >
> > I don't believe that bypassing the objc abstraction layer is a good
> > idea.
> >
> > GNUstep and GNU ObjC have been ported to platforms that may not be
> > supported be pthreads.  In particular  I remember that FreeBSD at on
> > point used a different threading library that claimed POSIX/pthread
> > compatibility.
> >
> > I would instead try to create a libobjc test case a report a bug  
> > against
> > libobjc to get it fixed there.  Now with all this ObjC 2.0 activity I
> > would believe that someone would have get GCC libobjc up to par anyway
> > on these platforms to be able test it there anyway.
> >
> 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.

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.

Cheers,
David