From: Richard M Kreuter <kreuter@pr...> - 2008-06-01 14:30:50
> In any case, it is just NOT POSSIBLE to safely share data between an
> interrupted program and an asynchronous signal handler. Typical
> condition: the signal arrives before you setup the shared
> datastructure, and the signal handler has nowhere to store things.
> Worse: you need to grab some mutex on the datastructure or otherwise
> modify it, and the handler pops in just in the middle of that
> operation. "Solution": disable the signal handler (for all threads! Of
> course, in practice it is only safe for only one thread to handle
> signals non-trivially) around any write operation on the shared
> datastructure. But if you're ready to pay that cost, you may as well
> do wholly without signal handler and just poll using waitpid when you
> want to read the child status, or use a signalfd in your event loop,
> etc. Or if you really love threads, have the signal handler just wake
> up a waiting thread (may as wel use a sigfd at least on linux). And
> yes, I ran into this run-program race condition in real life.
FWIW, I believe it turns out that Windows doesn't offer an analogue of
SIGCHLD (and so, I think, RUN-PROGRAM doesn't fully work there at
present). So I think the thing to do on Windows is to deal with child
processes in the event loop, and if that's the way to go on Windows,
then (modulo the details) I think it might be worthwhile to use the same
approach on Unix, too.