By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,400 Members | 903 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,400 IT Pros & Developers. It's quick & easy.

Odd behavior with os.fork and time.sleep

P: n/a
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"

Sep 16 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a
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
Sep 16 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.