>> [...] wake up the main line?
> I like the "pipe to self" method primarily because it doesn't rely on
> atomicity of *anything* -- it's entirely asynchronous.

Unfortunately, unless carefully written, it does have
constipation-deadlock potential.  If enough signals are delivered, fast
enough that the main line doesn't get to run for long enough, the pipe
can fill up and the process can deadlock against itself trying to write
wakeup bytes to it.

This is avoidable, but it takes a little care and some careful
"volatile"s to make sure it's safe.

> Manuel's hack relies on the atomicity of a structure copy WRT the
> signal handler (and therefore needs to guarantee that).  My timeval
> hack relies on the atomicity of the system call entry and timeval
> copy WRT the signal handler.

...and therefore needs to guarantee _that_. :-/  (Actually, as long as
select is a syscall, this is probably safe; see my other note about
systems where select is a userland wrapper.)

And the pipe hack relies on buffering in the pipe.

Of course, with careful coding it can be reduced to demanding only one
byte of buffering, which is probably safe, and at the cost of a few
more syscalls, even that can be eliminated by, rather than writing to
the pipe, using shutdown(SHUT_WR) to wake up the select and then
recreating the pipe in the main line.

I suppose it all comes down to: how paranoid is it worthwhile being?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B