From owner-freebsd-arch@FreeBSD.ORG Wed Oct 10 14:28:06 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 4851A16A41A for ; Wed, 10 Oct 2007 14:28:06 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 1DEF113C448 for ; Wed, 10 Oct 2007 14:28:06 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 850DB1A4D82; Wed, 10 Oct 2007 07:28:05 -0700 (PDT) Date: Wed, 10 Oct 2007 07:28:05 -0700 From: Alfred Perlstein To: Jeff Roberson Message-ID: <20071010142805.GU31826@elvis.mu.org> 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> User-Agent: Mutt/1.4.2.3i Cc: Kostik Belousov , 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: Wed, 10 Oct 2007 14:28:06 -0000 * Jeff Roberson [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