|
From: | David Chisnall |
Subject: | Re: Deadlock in NSLog |
Date: | Mon, 4 Aug 2008 12:56:51 +0100 |
On 4 Aug 2008, at 12:46, David Ayers wrote:
Just to make my position clear. I personally have no issue if libobjcrequired a working POSIX threads implementation and the legacy threadingsupport is removed from libobjc [in fact it may already have beendeactivated]. But I do believe this should be fixed in libobjc and notworked 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 NetBSDand pth?). What is relevent is which specific threading library libobjcwas 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 configuredwith 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... itshould be fixed in "mainline" libobjc first.
I don't care whether libobjc uses its own threading implementation or not, however there is no reason for GNUstep to be using an inefficient and potentially (in this case, definitely) buggy wrapper around pthreads, rather than using pthreads directly. The threading abstraction in libobjc implements the minimal functionality required for libobjc, not the minimal functionality required in general, or required for GNUstep.
NSRecursiveLock is implemented on top of objc_mutex, which emulates a recursive mutex on top of a non-recursive pthread (or other platform- specific) mutex. Quite how this makes more sense than using a recursive pthread mutex is beyond me. On platforms without native pthreads support, there are pthread-compatibility libraries that are a lot better tested for general-purpose use than the libobjc code.
libobjc has to support more platforms than GNUstep. For example, it supports VxWorks and Windows directly. In order to use GNUstep on these platforms, you need a POSIX API layer, such as cygwin or mingw, which implements its own pthread wrapper. If you do this, then some code will be using the cygwin / mingw / whatever wrapper code around the native APIs, and some will be using the libobjc wrapper around the native APIs.
Since GNUstep depends on POSIX for a lot of -base, I see no reason why it can't use POSIX functions.
David
[Prev in Thread] | Current Thread | [Next in Thread] |