Date: Thu, 7 Mar 2002 17:54:21 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Alfred Perlstein <bright@mu.org> Cc: arch@freebsd.org Subject: Re: Contemplating THIS change to signals. (fwd) Message-ID: <Pine.BSF.4.21.0203071751480.37321-100000@InterJet.elischer.org> In-Reply-To: <20020308002922.GO26621@elvis.mu.org>
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: > > > > > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0203071751480.37321-100000>