From owner-freebsd-arch Thu Dec 27 9:40:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 1C3AA37B405 for ; Thu, 27 Dec 2001 09:40:10 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011227174008.HUDR20122.rwcrmhc53.attbi.com@InterJet.elischer.org>; Thu, 27 Dec 2001 17:40:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id JAA88172; Thu, 27 Dec 2001 09:26:49 -0800 (PST) Date: Thu, 27 Dec 2001 09:26:48 -0800 (PST) From: Julian Elischer To: Alfred Perlstein Cc: arch@freebsd.org Subject: Re: the condvar stuff. In-Reply-To: <20011227040146.A55891@elvis.mu.org> 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 On Thu, 27 Dec 2001, Alfred Perlstein wrote: > * Julian Elischer [011227 03:20] wrote: > > need to be able to cancel any cv or msleep in a threads world... Well I > > don't NEED to but if I can't cancel a thread waiting on a cv then exit() > > can take arbitrarily long as the exiting thread has to wait for all the > > other threads to finish waiting on the CV. > > This is too much work. What you want to do is post signals to > each "thread", this will make all interruptable (PCATCH/cv_sig) > threads return up the syscall path. You may have to wait for > non PCATCH/cv_sig threads because you have no choice. Most of > those uninterruptable sleeps are there because it would be really > difficult to handle an abort at that stage or becuase you've loaned > out a resource that you must reclaim in order to "set right". > > For now you should just consider using the existing mechanisms, > something like a posted signal and not worry about the uninterruptable > sleeps. That's what I'm doing.... > > > Basically one of the changes I'll be doing in the KSE tree > > as that all msleeps and cv waits and sx waits and mutx waits have > > to either be identifiable as uninterruptable, or ba capable of > > being interrupted (so at least the next layer can catch it and back out). > > Yes, this is what PCATCH is for. I know, I'm just dissapointed at the ease that I have in finding cases where all I can do is wait... :-/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message