From owner-freebsd-arch@FreeBSD.ORG Fri Oct 26 15:49:29 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5842616A418 for ; Fri, 26 Oct 2007 15:49:29 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (meestal-mk5.stack.nl [IPv6:2001:610:1108:5010::149]) by mx1.freebsd.org (Postfix) with ESMTP id 1A42F13C4A3 for ; Fri, 26 Oct 2007 15:49:29 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 47E733FE1F; Fri, 26 Oct 2007 17:49:28 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 2FD07228C5; Fri, 26 Oct 2007 17:49:28 +0200 (CEST) Date: Fri, 26 Oct 2007 17:49:28 +0200 From: Jilles Tjoelker To: Jeff Roberson Message-ID: <20071026154927.GA13135@stack.nl> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071009182046.J912@10.0.0.1> X-Operating-System: FreeBSD 6.2-STABLE i386 User-Agent: Mutt/1.5.16 (2007-06-09) Cc: arch@freebsd.org Subject: Re: Abolishing sleeps in issignal() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2007 15:49:29 -0000 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