Odd behavior with os.fork and time.sleep

[Yin]

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?

Linux Fedora Core 4
Python 2.4.1

Thanks.

#!/usr/bin/env python

import os, time
import signal
import sys

def chldhandler(signum, stackframe):
while 1:
try:
result = os.waitpid(-1, os.WNOHANG)
except:
break
print "Reaped child process %s" % result[0]
signal.signal(signal.SIGCHLD, chldhandler)

signal.signal(signal.SIGCHLD, chldhandler)

pid = os.fork()
if pid: # parent
print "Parent. Child is %d" % pid

try:
os.kill(pid, 0)
print "Killed child"
os.kill(pid, signal.SIGKILL)
except OSError, err:
print "Child is dead"

print "In parent again"
time.sleep(4)
time.sleep(4)

print "Parent awake"
else: # child
print "Child sleeping 5 seconds..."
time.sleep(5)
print "Child awake"

[Donn Cave]

In article <11*********************@f14g2000cwb.googlegroups. com>,
"Yin" <yi*******@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, do**@u.washington.edu