In article < XXXX@XXXXX.COM >,
If you can possibly revise your design to avoid the need
for this, by all means do so.
The SIGCHLD signal interrupts functions like sleep(), and
that's what you're seeing: the parent process didn't return
to its sleep after handling the signal. What's worse, it
affects other functions in a similar way, such as I/O. Try
to read some input from the terminal, instead if sleeping,
and you should crash with an EINTR error. Makes it harder
to write a reliable program, when you're inviting such trouble.
So far this is a low level UNIX issue that isn't peculiar to
Python, but Python adds to the difficulties just in the general
awkwardness of signal handling in an interpreted language,
where handlers may execute somewhat later than you would expect
from experience with lower level languages. And then if you
decide to add threads to the mix, there are even more issues
as signals may be delivered to one thread and handled in another,
If you're dispatching on I/O, for example with select, you
can use an otherwise unused pipe to notice the child fork's
exit -- close the parent's write end right away, and then
when the pipe becomes readable it must be because it closed
on child exit.
Donn Cave, XXXX@XXXXX.COM