RetroSearch Browse

Sun Dec 21 21:07:37 EST 2003 · https://mail.python.org/pipermail/python-dev/2003-December/041311.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-December/041311.html below:

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