Re: Abolishing sleeps in issignal()

On Tue, Oct 09, 2007 at 06:25:54PM -0700, Jeff Roberson wrote:
On Tue, 9 Oct 2007, Matthew Dillon wrote:

Sure, however, we already deal with interrupting these system calls now
either with short reads or syscall restart. The question is whether
changing the behavior to the same for SIGSTOP is a big enough change to
break things. I will see what posix has to say about it soon.

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.

I think quite a lot of programs assume that a short read on a regular
file means EOF or error, and a short write on a regular file is an
error. Making SIGSTOP interrupt partial read/write would break them.

On the other hand, postponing SIGSTOP handling just degrades the user
experience a little (and that can be improved again as mentioned
elsewhere in the thread).

--
Jilles Tjoelker
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Abolishing sleeps in issignal()
    ... Except for certain process control ... SIGSTOP is handled asynchronously anyway. ... somewhat bigger when it is handled in userret. ...
    (freebsd-arch)
  • Re: Abolishing sleeps in issignal()
    ... I think it's a bad idea to have SIGSTOP generate an EINTR-like event. ... trap layer and be able to restart it. ... Except for certain process control ... somewhat bigger when it is handled in userret. ...
    (freebsd-arch)