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.
Cheers,
David
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.
David
P.S. Andrew is very busy on other things at the moment, and I believe
I am the only person currently actively hacking on GNU libobjc. You
can find the experimental version in the Étoilé repository.
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev