|
»
»
« Return to Thread: Deadlock in NSLog
Re: Deadlock in NSLog
by David Chisnall
::
Rate this Message:
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@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev
> 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@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev
« Return to Thread: Deadlock in NSLog
| Free embeddable forum powered by Nabble | Forum Help |
