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

Subprocess and pipe-fork-exec primitive

P: n/a
Hi,

I am working with the subprocess.py module in Python 2.4.4 and I am
confused about it's functionality. It uses the standard pipe-fork-exec
method to start a subprocess:

# create pipes

pid = fork()

if pid == 0:
# child
exec(...)

# parent
status = waitpid(pid, 0)

From my experience, this primitive will fail with 'no child
processes' at the waitpid call if the forked child dies very quickly -
before the parent is scheduled back for execution. This seems to happen
because Python has a default SIGCHLD handler that, in this case, will
reap the process before the parent has the chance to do it.

I would like to know if this is correct, or am I missing something here?

---
Rafael.

Jul 30 '07 #1
Share this Question
Share on Google+
2 Replies


P: n/a
From my experience, this primitive will fail with 'no child processes'
at the waitpid call if the forked child dies very quickly - before the
parent is scheduled back for execution. This seems to happen because
Python has a default SIGCHLD handler that, in this case, will reap the
process before the parent has the chance to do it.
What operating system is your experience from? On a POSIX system,
this should not happen - i.e. delivery of SIGCHLD should not cause
to make the child waited-for. Python itself does not perform wait()
in response to SIGCHLD.
I would like to know if this is correct, or am I missing something here?
You must be missing something, although I'm uncertain what precisely
that is.

Regards,
Martin
Jul 31 '07 #2

P: n/a
Hi Martin,

the operating system I'm using is SUSE Linux 10, kernel 2.6.13.

You're right, I was missing something. After you told me that it
couldn't be Python preforming wait() on SIGCHLD, I decided to
investigate further.

My application requires access to a Informix database, and uses
informixdb. The problem seems to be related to that module. I wrote a
small piece of code to test it:

---------------------------------------------------
#!/usr/bin/env python

from os import fork, execl, waitpid
from informixdb import connect

try:
conf = {}
conf['dsn'] = 'db@server'
conf['user'] = 'user'
conf['password'] = 'password'
connection = connect(**conf)

except:
pass

pid = fork()

if pid == 0:
# Child
execl("/bin/sh", "/bin/sh", "-c", "true")

# Parent
waitpid(pid, 0)

print pid
---------------------------------------------------

If you run the code above multiple times, some runs will trigger
exceptions on the waitpid calls. Commenting the call to
informixdb.connect(), no exceptions are triggered. I am concluding that
informixdb, not Python, is handling the signals and reaping the
subprocesses.

Now Martin, do you think I can use informixdb.py and subprocess.py in
the same application? I was thinking on forking subprocesses from the
main thread and using other threads to access the Informix database,
would that work?

Thanks,
Rafael.

Martin v. Lwis escreveu:
> From my experience, this primitive will fail with 'no child processes'
at the waitpid call if the forked child dies very quickly - before the
parent is scheduled back for execution. This seems to happen because
Python has a default SIGCHLD handler that, in this case, will reap the
process before the parent has the chance to do it.

What operating system is your experience from? On a POSIX system,
this should not happen - i.e. delivery of SIGCHLD should not cause
to make the child waited-for. Python itself does not perform wait()
in response to SIGCHLD.
> I would like to know if this is correct, or am I missing something here?

You must be missing something, although I'm uncertain what precisely
that is.

Regards,
Martin


Aug 1 '07 #3

This discussion thread is closed

Replies have been disabled for this discussion.