From owner-freebsd-arch@FreeBSD.ORG Tue Oct 9 23:49:08 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 040E216A419 for ; Tue, 9 Oct 2007 23:49:08 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id B1D9D13C44B for ; Tue, 9 Oct 2007 23:49:07 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.1/8.13.7) with ESMTP id l99Nn0la073432; Tue, 9 Oct 2007 16:49:00 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.1/8.13.4/Submit) id l99Nn01S073431; Tue, 9 Oct 2007 16:49:00 -0700 (PDT) Date: Tue, 9 Oct 2007 16:49:00 -0700 (PDT) From: Matthew Dillon Message-Id: <200710092349.l99Nn01S073431@apollo.backplane.com> To: Kostik Belousov References: <20071008142928.Y912@10.0.0.1> <20071009100259.GW2180@deviant.kiev.zoral.com.ua> 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: Tue, 09 Oct 2007 23:49:08 -0000 I think it's a bad idea to have SIGSTOP generate an EINTR-like event. The two have totally different mechanics and the system call behavior will be different because there are some system calls which simply cannot be restarted even if you wanted to. System calls which loop on UIO's, for example, cannot be restarted. EINTR and STOP have two totally different behaviors for such calls and there is nothing you can do about it. Basically any system call which maintains state through multiple blocking events cannot be restarted after having returned unless no cumulative operations have been performed. For example, if read()ing from a socket the read() is restartable ONLY if no data has yet been read. But if some data HAS been read and EINTR occurs, the system call will simply terminate early and return a short-read, and NOT restart. That same system call when presented with a STOP, however, will not terminate early. Instead it (in FreeBSD now) stops in tsleep and when it is CONTed again the system call resumes. It's simply not possible (without a LOT of work) to have such a system call return all the way to userland or even return to the kernel syscall trap layer and be able to restart it. 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. -Matt