On 6 Jan 2008, at 17:31, Matt Rice wrote:
On Jan 6, 2008 6:02 AM, Richard Frith-Macdonald
<[EMAIL PROTECTED]> wrote:
On 6 Jan 2008, at 10:41, David Wetzel wrote:
OK ... so errno 0 means that the operating system is not reporting
any error ... supporting the idea that the thread detach is
succeeding.
pthread functions return an error code, so no need to set errno, if it
did set errno wouldn't you have to lock it every time so another
thread didn't overwrite it, unfortunately this stuff just gets lost in
objc_thread_detach.
If a thread detach fails due to some other system call, then that
system call will have set errno ... so I think it's worth looking at
errno for clues even though it's not a reliable dignopstic.
Possibly what you are seeing is an objc runtime bug such that the
detach succeeds but appears to fail because the thread ID is zero?
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18573
I don't believe this is it this time, after testing the pthread
library i've yet to see it return a thread id of 0
though at this point it is not possible to definitively say
I suppose it does seem unlikely.
No idea. Do you have a test program for that?
Nope ... I guess you would need to build the runtime with debug, so
you could step through into the runtime method to detach the thread,
and see what thread Id the underlying call is returning, and what
error status it is returning.
I did this which is where i came up with -pthread it was failing in
the call to __gthread_active_p()
in __objc_thread_detach from posix.h iirc,
which looks for the symbol pthread_cancel,
but of course it still fails when passing -pthread to the stock
compiler/libobjc
so at this point i'm stuck wrt getting it working or figuring out
whats wrong with the stock compiler
and can only offer work arounds such as using the libobjc from
gnustep, or building a compiler which works when -pthread is passed
So this appears to be a compiler/runtime bug on NetBSD.
Building your own gcc/runtime is not good advice for most people :-(
Anyway, it looks like you probably have a gcc/runtime problem rather
than an gnustep problem. You could try to confirm that by writing a
little test program to detach a thread using the objc api directly
and not linking with any gnustep stuff.
eg. something like
it seems to me objc_thread_detach is kind of broken
it can fail in multiple ways and only has 1 error code (NULL)
and that error code conflicts with a non-failure on certain platforms
because it is merged with the thread id.
it'd be nice if it accepted an address to a thread id as an argument
and returned an error code, like pthreads
Yes, I think the existing design is poor ... perhaps if we suggested
the improvement to the objc maintainter ...
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev