On 4 Aug 2008, at 12:46, David Ayers wrote:
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.
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
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
