os.system vs os.system inside thread -> why is there any difference?

[Jeff Epler]

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
packet.

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:
http://mail.python.org/pipermail/python-dev/2003-December/041311.html
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.

Jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20041117/2196fd97/attachment.sig>