Date: Thu, 7 Mar 2002 19:57:19 -0500 (EST) From: Jeff Roberson <jroberson@chesapeake.net> To: bright@mu.org Cc: julian@elischer.org, <arch@freebsd.org> Subject: Re: Contemplating THIS change to signals. (fwd) Message-ID: <20020307195241.M64788-100000@mail.chesapeake.net> In-Reply-To: <E68F4182B5EFBE42A503F10FCB75FEDE04AD5B@EX1.midstream.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 7 Mar 2002, Alfred Perlstein wrote: > > * Alfred Perlstein <bright@mu.org> [020307 16:25] wrote: > > * Julian Elischer <julian@elischer.org> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020307195241.M64788-100000>