From owner-freebsd-arch Thu Mar 7 16:57:33 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by hub.freebsd.org (Postfix) with ESMTP id D476C37B402 for ; Thu, 7 Mar 2002 16:57:29 -0800 (PST) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id g280vJ666244; Thu, 7 Mar 2002 19:57:19 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Thu, 7 Mar 2002 19:57:19 -0500 (EST) From: Jeff Roberson To: bright@mu.org Cc: julian@elischer.org, Subject: Re: Contemplating THIS change to signals. (fwd) In-Reply-To: Message-ID: <20020307195241.M64788-100000@mail.chesapeake.net> 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: > > > > 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. Am I missing something? Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message