[Python-Dev] Python threads end up blocking signals in subprocesses (original) (raw)
Jeff Epler jepler at unpythonic.net
Mon Dec 22 09:03:17 EST 2003
- Previous message: [Python-Dev] Python threads end up blocking signals in subprocesses
- Next message: [Python-Dev] Python threads end up blocking signals in subprocesses
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Mon, Dec 22, 2003 at 03:46:14AM +0100, Martin v. Loewis wrote:
I'd think so, yes. The patch needs to be elaborated, and I'd delay integration to wait for a Redhat response.
Well, unlike the last two bugs I filed in redhat bugzilla, this one has already seen some activity. I hope they don't take the line that this is not a bug :(
------- Additional Comments From jakub at redhat.com 2003-12-22 03:53 ------- Why? There is no word about system() in http://www.opengroup.org/onlinepubs/007904975/functions/pthread_atfork.html and there doesn't seem to be anything in http://www.opengroup.org/onlinepubs/007904975/functions/system.html that would mandate system() to be implemented using fork() function.
------- Additional Comments From jepler at unpythonic.net 2003-12-22 08:01 ------- I base my claim that pthread_atfork() should be called by system() from reading http://www.opengroup.org/onlinepubs/007904975/functions/system.html
The third paragraph under the heading "description" says this: "[CX] 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() as follows [...]"
The rationale section expands on what the "environment of the executed command" is: "IEEE Std 1003.1-2001 places additional restrictions on system(). It requires that if there is a command language interpreter, the environment must be as specified by fork() and exec. This ensures, for example, that close-on- exec works, that file locks are not inherited, and that the process ID is different."
The pthread_atfork web page says it "provides multi-threaded application programs with a standard mechanism for protecting themselves from fork() calls in a library routine or the application itself." I believe that system() is one such library routine, since it is specified to create an environment "as specified by fork()".
This issue arose in the context of Python. For various reasons, signals are blocked in all threads besides the main thread. This means that in processes generated by fork() from subthreads, all signals are blocked, which leads to undesired behavior. Using the child argument of pthread_atfork() allows signals to be unblocked when using fork()+exec() to execute an external program, but not when system() is used.
- Previous message: [Python-Dev] Python threads end up blocking signals in subprocesses
- Next message: [Python-Dev] Python threads end up blocking signals in subprocesses
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]