Abolishing sleeps in issignal()
Alfred Perlstein
alfred at freebsd.org
Wed Oct 10 07:28:06 PDT 2007
* Jeff Roberson <jroberson at 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
More information about the freebsd-arch
mailing list