Odd behavior with os.fork and time.sleep

[Donn Cave]

In article <1126888834.712275.91470 at f14g2000cwb.googlegroups.com>,
 "Yin" <yin_12180 at yahoo.com> wrote:
> I am writing a script that monitors a child process.  If the child
> process dies on its own, then the parent continues on.  If the child
> process is still alive after a timeout period, the parent will kill the
> child process.  Enclosed is a snippet of the code I have written.  For
> some reason, unless I put in two time.sleep(4) commands in the parent,
> the process will not sleep.  Am I forgetting something?  Any reasons
> for this strange behavior?

...
> signal.signal(signal.SIGCHLD, chldhandler)

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,
etc.

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, donn at u.washington.edu