[Python-Dev] Python threads end up blocking signals in subprocesses

Jeff Epler jepler at unpythonic.net
Sun Dec 21 21:07:37 EST 2003

On Mon, Dec 22, 2003 at 02:08:34AM +0100, Martin v. Loewis wrote:
> With this fork() implementation, atfork handlers won't be invoked,
> which clearly looks like a bug to me. You might want to upgrade glibc
> to glibc-2.3.2-27.9.7.i686.rpm and nptl-devel-2.3.2-27.9.7.i686.rpm.
> In this version, the definition of FORK is changed to

I also tested a fedora machine with 
and the pthread_atfork handler is still not called for system().

Opengroup's documentation for system() says
	[...] The environment of the executed command shall be as if a
	child process were created using fork(), and the child process
	invoked the sh utility using execl() [...]


so this looks like a glibc/nptl bug.  I filed it in redhat's bugzilla:

Given all this, does it make sense to adopt a patch similar to the one
I posted earlier, and ignore the bug in system() on any particular OS?
system() and popen() are easy to replace in Python if anybody is really
bothered by the problem.


More information about the Python-Dev mailing list