Re: [Qemu-devel] [PATCH 01/13] Handle terminating signals.

[Jamie Lokier <jamie@shareable.org>]

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