Date: Wed, 10 Oct 2007 07:28:05 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: Jeff Roberson <jroberson@chesapeake.net> Cc: Kostik Belousov <kostikbel@gmail.com>, arch@freebsd.org Subject: Re: Abolishing sleeps in issignal() Message-ID: <20071010142805.GU31826@elvis.mu.org> In-Reply-To: <20071009182046.J912@10.0.0.1> References: <20071008142928.Y912@10.0.0.1> <20071009100259.GW2180@deviant.kiev.zoral.com.ua> <200710092349.l99Nn01S073431@apollo.backplane.com> <20071009182046.J912@10.0.0.1>
next in thread | previous in thread | raw e-mail | index | archive | help
* Jeff Roberson <jroberson@chesapeake.net> [071009 18:24] wrote: > On Tue, 9 Oct 2007, Matthew Dillon wrote: > > > The restart code only works if no cumulative events have occured... for > > example, if a UIO has not been filled at all (0 bytes read or written). > > ERESTART literally moves the program counter back to the start of the > > system call and causes userland to re-execute it. > > > > The best compromise that I found, which I implemented for Dragonfly a > > while back, was to ignore SIGSTOP in the kernel entirely and process > > the event in userret() instead. Except for certain process control > > cases like the debugger, SIGSTOP is handled asynchronously anyway. e.g. > > when you signal a SIGSTOP the kill() system call will return before > > the target process(es) have actually stopped. It's just that the window > > of opportunity is fairly small when SIGSTOP is handled in tsleep, and > > somewhat bigger when it is handled in userret. That's the only hangup. > > Yes this is a very good idea. However, it's also a change in behavior. > The question is, which is more disruptive? Causing restart behavior or > allowing the syscalls to continue further than they original would've. I > will consult posix and see what Linux and Solaris do in more detail. You may be able to fix those situations by manually calling into "check_sstop()" in those code paths. -- - Alfred Perlstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071010142805.GU31826>