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

[przemas_r at o2.pl]

Thanks for the answer.
I've rewritten my code to use fork and exec calls instead of system 
call, but it still works only if run outside a thread. Here is the snippet:

def ipState (self, ip):
	if os.fork () == 0:
		command = 'arping -f -w %s -c %s -I %s %s' % (self.wait, 		 
self.count, self.iface, ip)
		os.execvp ('arping', command.split ())
		os._exit ()
	else:
		status = os.wait () [1] & 0xff
		print status

Changing start () to run () at the point where thread class is created 
and started (and thus running in main proccess instead) will cause the 
arping command to run properly. So the problem remains the same.

Jeff Epler wrote:
> 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