> > Yeah I know of the "self pipe" trick, I haven't benchmarked it yet. But I
> > suspect that the need to start taking EINTRs all over the place might
> > hurt. Especially since you'll take an EINTR while in select() because of
> > the SIGCHLD, then restart the select(), then find out it's a dead child,
> > and read(). So it costs a signal, a write(), a select() and a read().
>
> Hmm. The EINTRs rather ruin the point. After I sent the
> previous mail I started having serious doubts about doing IO
> (even to a pipe or message queue) in a signal handler. Does
> it work? What is and isn't allowed?
What am I smoking ... child deaths don't happen often enough to worry
about EINTR causing performance problems. Instead of paying for a
wait/select on every iteration I can just pay for a select(). Duh. I'll
go benchmark that.
> Posix.1b also has a neat feature (which I didn't see before)
> which is that you can run with the interesting signals
> blocked, and then do a sigwaitinfo(). This syscall waits
> until one of a set of signals appears, and then doesn't call
> the handler at all, but rather returns, and lets you call it
> synchronously. This seems very cool, as it allows you to
> avoid all that troublesome (slow!) setting up of a signal
> handler stack etc. You don't have to do any pipe tricks, you
> can just get on with it. In combination with SIGIO and
> signals delivered on AIO completion, it should be just what
> you need.
Yes this does sound cool, and right on the money... as long as multiple
threads can block and only one thread gets each queued signal ;)
Dean