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'] = '[EMAIL PROTECTED]'
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. Löwis 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
--
http://mail.python.org/mailman/listinfo/python-list
