[Python-Dev] Python threads end up blocking signals in subprocesses (original) (raw)

Martin v. Loewis martin at v.loewis.de
Sun Dec 21 20:08:34 EST 2003

Jeff Epler wrote:

When using pthreadatfork, os.system never triggers my code. However, reimplementing os.system in terms of os.fork+os.execv, it does. I don't know if this is right or wrong according to pthread, but since it doesn't work on my platform the question is academic for me.

Interesting. I'd be curious to find out why this fails - it may be a bug in your system, in which case I'd say "tough luck, complain to the system vendor" (for Redhat 9, I'm tempted to say that anyway ...)

Looking at what likely is the source of your system(3) implementation (glibc 2.3.2, sysdeps/unix/sysv/linux/i386/system.c), I see that the fork used inside system(3) is

define FORK() \

INLINE_SYSCALL (clone, 3, CLONE_PARENT_SETTID | SIGCHLD, 0, &pid)

Atleast, this is the fork being used if __ASSUME_CLONE_THREAD_FLAGS is defined, which is the case for Linux >2.5.50.

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

#if defined __ASSUME_CLONE_THREAD_FLAGS && !defined FORK

define FORK() \

INLINE_SYSCALL (clone, 3, CLONE_PARENT_SETTID | SIGCHLD, 0, &pid) #endif

which might actually do the right thing, assuming FORK is already defined to one that calls the atfork handlers.

Wouldn't the PyOSAfterFork approach also require python to provide its own versions of any POSIX APIs that would typically be implemented in terms of fork (system(), popen(), and spawn*() come to mind)?

You are right. system(3) won't call our version of fork, so PyOS_AfterFork won't be invoked. So forget about this approach.

Regards, Martin

More information about the Python-Dev mailing list