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