From owner-freebsd-arch Fri Mar 8 0:25:31 2002 Delivered-To: freebsd-arch@freebsd.org Received: from gnuppy.monkey.org (wsip68-15-8-100.sd.sd.cox.net [68.15.8.100]) by hub.freebsd.org (Postfix) with ESMTP id 16BC737B402 for ; Fri, 8 Mar 2002 00:25:29 -0800 (PST) Received: from billh by gnuppy.monkey.org with local (Exim 3.35 #1 (Debian)) id 16jFgV-0001kC-00; Fri, 08 Mar 2002 00:25:03 -0800 Date: Fri, 8 Mar 2002 00:25:03 -0800 To: Julian Elischer Cc: Nate Williams , Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: Contemplating THIS change to signals. (fwd) Message-ID: <20020308082503.GA6690@gnuppy.monkey.org> References: <15496.22850.811384.136422@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i From: Bill Huey Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Mar 08, 2002 at 12:08:49AM -0800, Julian Elischer wrote: > No, it is not really interrupted. It has not been sent back to the > userland. A STOP certainly doesn't prematurely kill it. > Its stack still says that it is in the sleep. > If the SIGCONT occurs, it is still in the sleep where it was before > an if not, the timeout timer is still running.. > > An interrupted sleep is when the timeout is cancelled and control is > returned so that it goes back towards the userland. This does not > happen in a syscall when a SIGSTOP is received. The way I read it was that both of those things are a kind of notification to that system call and not literally an interrupt that absolutely must return it back to userspace some how. > > 2) Completes, but has a return value such that the userland program can > > re-start the system call again. > > This is never the result of a STOP signal detected in msleep(tsleep) > > In both cases, it has been 'interrupted' (it did not complete as it > > would had it not received a SIGSTOP signal). > > SIGSTOP does not do this (unless you have set a signal handler for it > in which ccase it is no longer SIGSTOP but rather something else > (in fact CAN you set a SIGSTOP handler?) Don't remember, signals are evil. ;) bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message