Date: Wed, 2 Dec 1998 16:28:15 +1100 (EST) From: John Birrell <jb@cimlogic.com.au> To: scrappy@hub.org (The Hermit Hacker) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: pthread_cancel() function... Message-ID: <199812020528.QAA07636@cimlogic.com.au> In-Reply-To: <Pine.BSF.4.05.9812020053410.4737-100000@thelab.hub.org> from The Hermit Hacker at "Dec 2, 98 00:57:14 am"
next in thread | previous in thread | raw e-mail | index | archive | help
The Hermit Hacker wrote: > Very sure, but the developer has been *very* receptive to fixes > and patches that I've sent him...what would you suggest? Just replace > with pthread_detach() if pthread_cancel() doesn't exist? Or something > altogether different? pthread_detach() just indicates to the system that the thread exit status and thread resources can be thrown away. The normal thing for one thread to do is to discover (by some mechanism, usually by accessing shared data) that another thread has exited. The running thread then joins to the other thread to get it's exit status and then detaches it. This is very different to pthread_cancel() which is intended for use when one thread wants to play god over other threads. If your application requires pthread_cancel() because there is no other means for the 'god' thread to tell other threads to exit, then we need to implement pthread_cancel(). 8-) Can you send me the URL for the application so I can have a look at how the thread cancellation is coded? This shouldn't be necessary, but experience has proven otherwise. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812020528.QAA07636>