From owner-freebsd-arch Thu Mar 7 18: 0:36 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 9258537B400 for ; Thu, 7 Mar 2002 18:00:23 -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 <20020308020020.LWRS1147.rwcrmhc52.attbi.com@InterJet.elischer.org>; Fri, 8 Mar 2002 02:00:20 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA45418; Thu, 7 Mar 2002 17:59:17 -0800 (PST) Date: Thu, 7 Mar 2002 17:59:17 -0800 (PST) From: Julian Elischer To: Jeff Roberson Cc: bright@mu.org, arch@freebsd.org Subject: Re: Contemplating THIS change to signals. (fwd) In-Reply-To: <20020307195241.M64788-100000@mail.chesapeake.net> 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, Jeff Roberson wrote: > > > On Thu, 7 Mar 2002, Alfred Perlstein wrote: > > > > > * Alfred Perlstein [020307 16:25] wrote: > > > * Julian Elischer [020307 14:00] wrote: > > > > > > 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. > > > > Wouldn't it be reasonable to ignore the stop until we return to the user? > This way we could continue to honor all other signals inside msleep, which > seems to be very desirable. We should just postpone the STOP until we > actually return to the user. That's basically what I want to do. set a flag saying "We've been stopped" and leave. When we get to teh user boundary we stop if it's set. not too hard really. > > Am I missing something? I don't thinksoi, but that's why I'm asking.. Im also hoping to hear from kirk since we inherritted this behaviour from 4.4lite2 > > Jeff > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message