From owner-freebsd-hackers Wed Mar 6 10:49:29 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 6515337B402; Wed, 6 Mar 2002 10:49:17 -0800 (PST) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.1/8.12.1) with ESMTP id g26InFWH013437; Wed, 6 Mar 2002 13:49:15 -0500 (EST) Date: Wed, 6 Mar 2002 13:49:15 -0500 (EST) From: Daniel Eischen To: Martin Blapp Cc: deischen@freebsd.org, rittle@labs.mot.com, alfred@freebsd.org, hackers@freebsd.org Subject: Re: Sun idlc broken with our libc_r [Please help] In-Reply-To: <20020306191026.U56721-100000@levais.imp.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message