Am Montag, den 04.08.2008, 12:56 +0100 schrieb David Chisnall: > 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.
That assumes that ObjC code using GNUstep also does not use the libobjc API directly for certain features that OpenStep/Cocoa did/does not export. I don't believe that is a safe assumption. In fact I would be very surprised if code that uses threading in meaingfull ways does not rely on some of those features. > 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. If this wrapper is broken, then please file a bug (or even fix it since this seems to be the pthread implementation which you are refering to). > Quite how this makes more sense than using a > recursive pthread mutex is beyond me. Because libobjc wraps the threading API for a reason. I don't claim to know all the reasons. I'm weary of ignoring them since debugging those issues is painful. So if libpthread (note I'm not stating POSIX... but a specific implementation that -base would link to). > 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. I cannot asses that evaluation, but I do clearly see a benifit in fixing libobjc rather than working around this in -base. If those pthread-compatibility libraries are so much better, then libobjc should be using them. I have no issue with that. In fact I think it would be great if libobjc could be simplified in this fasion. > 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. Well, there is a lot of code in -base that you would have adapt to remove the dependency of libobjc's threading implementation. In fact I'm not even sure if the NSWillBecomeMutlithread hook can reliably be called via the libobjc runtime if -base was configured with a different threading library than libobjc. (Of course it would happen to work if the threading libraries happend to be identical). But maybe you can explain why you do not seem to see an merit in fixing the libobjc wrapper. Cheers, David _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev