Date: Thu, 27 Dec 2001 15:59:45 -0500 (EST) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Julian Elischer <julian@elischer.org> Cc: Mike Smith <msmith@FreeBSD.ORG>, Alfred Perlstein <bright@mu.org>, arch@FreeBSD.ORG Subject: Re: the condvar stuff. Message-ID: <Pine.SUN.3.91.1011227154432.11903A-100000@pcnet1.pcnet.com> In-Reply-To: <Pine.BSF.4.21.0112271135510.84622-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 27 Dec 2001, Julian Elischer wrote: > so, is there such a thing in > pthread condvars as an uncancellable condvar? Sort of. Cancellability is a separately managed thing. Threads have a cancel state and type. You can enable or disable the cancel state to allow or disallow cancellation, and you can set the cancel type to deferred or asynchronous cancellation. Threads in pthread_cond_wait, pthread_mutex_lock, etc, can be cancelled if their state and type allow them to be cancelled. They can also be signaled to allow a signal handler to run regardless of whether they are in a pthread_cond_wait, pthread_mutex_lock, etc., blocking condition. See pthread_setcancelstate, pthread_setcanceltype, etc. One thing about cancelling a thread in pthread_cond_wait is that the mutex is relocked by the thread after the cancellation. The thread needs to install a cleanup function (to be run at thread exit) that can unlock the mutex (see pthread_cleanup_push, pthread_cleanup_pop). I don't think you want all the cancellation facilities of the pthread library in the kernel. It is probably sufficient just to have the _sig synchronization variants (as Solaris seems to get by with this). Some might argue for being able to push thread cleanup handlers in the kernel, though... -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.1011227154432.11903A-100000>