[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
glibc-2.3.2-101.1
nptl-devel-2.3.2-101.1
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() [...]
http://www.opengroup.org/onlinepubs/007904975/functions/system.html
so this looks like a glibc/nptl bug. I filed it in redhat's bugzilla:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=112517
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.
Jeff
More information about the Python-Dev
mailing list