[Python-Dev] Python threads end up blocking signals in
subprocesses
Martin v. Loewis
martin at v.loewis.de
Sun Dec 21 20:08:34 EST 2003
Jeff Epler wrote:
> When using pthread_atfork, 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 PyOS_AfterFork 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