|
»
»
« Return to Thread: Deadlock in NSLog
Re: Deadlock in NSLog
by David Chisnall
::
Rate this Message:
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.
>
> Cheers,
> David
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.
This is one of the reasons why the new runtime uses pthreads
directly. The abstraction layer in the GNU runtime is almost as big
as the entire codebase for the new runtime.
David
P.S. Andrew is very busy on other things at the moment, and I believe
I am the only person currently actively hacking on GNU libobjc. You
can find the experimental version in the Étoilé repository.
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev
> 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.
>
> Cheers,
> David
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.
This is one of the reasons why the new runtime uses pthreads
directly. The abstraction layer in the GNU runtime is almost as big
as the entire codebase for the new runtime.
David
P.S. Andrew is very busy on other things at the moment, and I believe
I am the only person currently actively hacking on GNU libobjc. You
can find the experimental version in the Étoilé repository.
_______________________________________________
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 |
