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 _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev