From owner-freebsd-arch Thu Mar 7 18: 0:28 2002 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 2525137B416 for ; Thu, 7 Mar 2002 18:00:19 -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 <20020308020018.LWQZ1147.rwcrmhc52.attbi.com@InterJet.elischer.org>; Fri, 8 Mar 2002 02:00:18 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA45398; Thu, 7 Mar 2002 17:54:23 -0800 (PST) Date: Thu, 7 Mar 2002 17:54:21 -0800 (PST) From: Julian Elischer To: Alfred Perlstein Cc: arch@freebsd.org Subject: Re: Contemplating THIS change to signals. (fwd) In-Reply-To: <20020308002922.GO26621@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, 7 Mar 2002, Alfred Perlstein wrote: > * Alfred Perlstein [020307 16:25] wrote: > > * Julian Elischer [020307 14:00] wrote: > > > > > > My suggestion is to remove teh code in issignal() that perfoms the > > > blocking actions and create a separate function that does that action. > > > I would then call that function from userret() immediatly after the call > > > to issignal(). The result would be that > > > suspended processes would still not reach userland, but processes would > > > not have to option of suspending indefinitly at sleep(). > > > > You are correct, you can _not_ allow arbitrary kernel threads to > > block indefinetly while potentially holding higher level locks. > > > > Please proceed with your planned work, it seems like the right > > thing to do. > > Both Poul-Henning Kamp and Nate Williams bring up the important > point of potentially long running syscalls, there are two > ways you might consider fixing this: > > 1) add an additional flag to msleep to allow suspension during sleep. > 2) restart the syscall at the userland boundry. Long running system calls behave the same. If the sleep in uninterruptable then in neither case is there a change. IF it's interruptable then either it suspends in the sleep and then immediatly heads for the user boundary. or it heads for the user boundary and suspends. Either way it looks the same from the outside.. it doesn't return to user space until the suspension is lifted. > > -- > -Alfred Perlstein [alfred@freebsd.org] > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message