From owner-freebsd-arch@FreeBSD.ORG Tue Oct 9 23:43:21 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 1E80216A418 for ; Tue, 9 Oct 2007 23:43:21 +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 C50C213C447 for ; Tue, 9 Oct 2007 23:43:20 +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 l99NX1Xe073288; Tue, 9 Oct 2007 16:33:02 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.1/8.13.4/Submit) id l99NX0qZ073285; Tue, 9 Oct 2007 16:33:00 -0700 (PDT) Date: Tue, 9 Oct 2007 16:33:00 -0700 (PDT) From: Matthew Dillon Message-Id: <200710092333.l99NX0qZ073285@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:43:21 -0000 I noticed the sigstop cascade with NFS a year or two ago and changed the way DragonFly handles SIGSTOP to no longer actually stop the process in the sleep code. What it does instead is set the process (or thread) state to SSTOP, but does not actually stop the process until the process tries to return to userland. All the stop handling was moved to userret(). It works just dandy, The only issue that cropped up from doing things this way is that when you ^Z a program that is blocked on I/O, the program will complete the I/O before actually going to sleep. This seems to only have a visible effect for programs outputting a lot of junk to stdout. One additional line will be written to stdout after the ^Z is delivered before the process actually stops. 'ps' output will also show the process not go into an immediate stop state but since the condition has to be flagged it is really easy to adjust ps to report that the process is stopped even though it isn't quite stopped yet. This change saved us a lot of headaches and simplified a number of code paths. Frankly, userret is the ONLY safe place where you can actually stop a process these days. -Matt