Date: Fri, 26 Oct 2007 17:49:28 +0200 From: Jilles Tjoelker <jilles@stack.nl> To: Jeff Roberson <jroberson@chesapeake.net> Cc: arch@freebsd.org Subject: Re: Abolishing sleeps in issignal() Message-ID: <20071026154927.GA13135@stack.nl> 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
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071026154927.GA13135>