os.system vs os.system inside thread -> why is there any difference?
jepler at unpythonic.net
Wed Nov 17 20:22:38 CET 2004
On POSIX systems, Python blocks the delivery of signals to threads, and
installs a 'pthread_atfork' handler to restore the default behavior when
fork() is called, because otherwise it leads to weird behavior in
programs started with fork+exec.
In the case of arping, I suspect the of the SIGALRM signal remains
blocked, and arping waits forever for either the signal or the return
On Linux, at least, system() never calls the pthread_atfork
handler, and the redhat maintainers have made it clear that they believe
this behavior is allowed by the Open Group unix specification.
Here's an entry-point into a python-dev thread on the subject:
with links to the Open Group specification and the closed redhat bug.
I suggest you write a replacement for system() in terms of fork + exec
and then you should get the behavior you want.
I continue to believe this is a redhat or glibc bug but my opinion
doesn't seem to matter.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
More information about the Python-list