From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KY2lF-0004xb-Cq
	for qemu-devel@nongnu.org; Tue, 26 Aug 2008 13:55:21 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KY2lE-0004x0-U5
	for qemu-devel@nongnu.org; Tue, 26 Aug 2008 13:55:20 -0400
Received: from [199.232.76.173] (port=51056 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KY2lE-0004wr-HZ
	for qemu-devel@nongnu.org; Tue, 26 Aug 2008 13:55:20 -0400
Received: from mail2.shareable.org ([80.68.89.115]:41309)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <jamie@shareable.org>) id 1KY2lD-0001jM-Uj
	for qemu-devel@nongnu.org; Tue, 26 Aug 2008 13:55:20 -0400
Date: Tue, 26 Aug 2008 18:55:18 +0100
From: Jamie Lokier <jamie@shareable.org>
Subject: Re: [Qemu-devel] [PATCH 01/13] Handle terminating signals.
Message-ID: <20080826175518.GD25893@shareable.org>
References: <1219336054-15919-1-git-send-email-kraxel@redhat.com>
	<1219336054-15919-2-git-send-email-kraxel@redhat.com>
	<m2n.s.1KWGbo-001Nr9@chiark.greenend.org.uk>
	<18611.56975.584280.471257@mariner.uk.xensource.com>
	<48B3F411.2020306@redhat.com>
	<18611.63711.631859.280983@mariner.uk.xensource.com>
	<48B3FDFA.2010905@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <48B3FDFA.2010905@redhat.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org
Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>

Gerd Hoffmann wrote:
> Ian Jackson wrote:
> > Gerd Hoffmann writes ("Re: [Qemu-devel] [PATCH 01/13] Handle terminating signals."):
> >> What this would be useful for?  The termination signals usualy one-shot
> >> anyway, so I don't see any advantage in doing the pipe-to-self trick.
> > 
> > The point is that then they can interrupt select().
> 
> Sure, basically any signal can interrupt any system call.  I still don't
> see the point you are trying to make.

Signals interrupting system calls has nothing to do with it.

The point is this sequence:

     1. Check for signals / flags from signals...  nope.

              [[ 2. Signal arrives!  Sets flag. ]]

     3. Call select().

The signal occurs _after_ the main loop checks for wakeup conditons,
but _before_ select() is called.  It doesn't interrupt select()
because that hasn't started yet.  Result: select() blocks for a long time.

In the fixed version, the signal handler writes to the self-pipe, and
select() is called in the main loop, and returns immediately because
the self-pipe is ready to read.  (The data in it is ignored, just read
to empty it.)

The other way this can be done is for the signal handler to call
siglongjmp().  But that's slower (every call to select() must call
sigsetjmp() which is a bit slow), and crashes some OSes.  The
self-pipe is well known for being reliable.

-- Jamie