From owner-freebsd-arch Thu Dec 27 13:20:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 02C2137B4CF; Thu, 27 Dec 2001 13:20:14 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011227212009.HDXM6450.rwcrmhc52.attbi.com@InterJet.elischer.org>; Thu, 27 Dec 2001 21:20:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA89230; Thu, 27 Dec 2001 13:16:45 -0800 (PST) Date: Thu, 27 Dec 2001 13:16:44 -0800 (PST) From: Julian Elischer To: Daniel Eischen Cc: Mike Smith , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: the condvar stuff. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is relevant of course because one of the things we need to impliment is a way that the userland can cancel a thread when it's off in the kernel. This is why I'm trying to figure out how to bring threads back from various 'stop-points' in the kernel On Thu, 27 Dec 2001, Daniel Eischen wrote: > 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