On Wed, 6 Mar 2002, Martin Blapp wrote:
> hi Daniel,
>
> > + pthread->join_status.thread = NULL;
> > + pthread->join_status.ret = NULL;
> > + pthread->join_status.error = 0;
>
> it still hangs :-(
Actually, the patch I gave you to uthread_detach was wrong. Here is
the correct one (apply by hand if you have to).
Index: uthread_detach.c
===================================================================
RCS file: /opt/FreeBSD/cvs/src/lib/libc_r/uthread/uthread_detach.c,v
retrieving revision 1.16
diff -u -r1.16 uthread_detach.c
--- uthread_detach.c 2001/05/20 23:08:32 1.16
+++ uthread_detach.c 2002/03/06 19:00:17
@@ -66,7 +66,9 @@
PTHREAD_NEW_STATE(joiner, PS_RUNNING);
/* Set the return value for the woken thread: */
- joiner->error = ESRCH;
+ joiner->join_status.error = ESRCH;
+ joiner->join_status.ret = NULL;
+ joiner->join_status.thread = NULL;
/*
* Disconnect the joiner from the thread being detached:
>
> How should a detach routine in the client code look like ? Does the client have
> to catch a signal or something ?
No, there is no signal. BTW, if the code is expecting a signal to
interrupt a join operation, it is wrong. A thread that is in a join
can catch a signal, but if it returns from the signal handler normally
(without longjmp'ing out of it) then it resumes the join operation.
That is why there is a loop in uthread_join.c. It is to allow
the thread to execute a signal handler and when it returns it
will resume the join operation. Removing the loop breaks signal
handling.
--
Dan Eischen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
