Abolishing sleeps in issignal()

[Jilles Tjoelker]

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