Threads, signals, and fork

Michael Hudson mwh at python.net
Thu Jul 4 09:24:19 EDT 2002


Mark Mitchell <markm at cup.hp.com> writes:

> Python 2.2 blocks signals in new threads:
> 
> 	/* Mask all signals in the current thread before creating the new
> 	 * thread.  This causes the new thread to start with all signals
> 	 * blocked.
> 	 */
> 	sigfillset(&newmask);
> 	SET_THREAD_SIGMASK(SIG_BLOCK, &newmask, &oldmask);
> 
> That means that if the thread calls fork(), all signals are blocked in
> the child process.

Not if you call fork() from the main thread, I think.

> This is not necessarily what the programmer wanted.
> 
> The blocking of signals for new threads is justified in the
> documentation for the signal module with the argument that since some
> systems do not allow you to send signals to individual threads, Python
> doesn't let you do it on any system.

I think it's also to get signal handlers to run in the main thread,
something Python promises.

> That argument is fine as far as it goes -- but since Python doesn't
> provide sigprocmask, there's no way to re-enable signals -- even for
> child processes.

I wrote and checked in a patch that exposed sigprocmask & friends.  It
behaved bizarrely on *so many* platforms that I disabled the configure
check that activates the new code until I work out how to proceed.
It's the fact that Python is linked as a multi-threaded program that
causes the problems, it seems.  See the python-dev archives for me
complaining about this quite a bit.

Interestingly, the behaviour on FreeBSD was deemed to be a bug in
their libc_r, but this only helps people who are running versions of
FreeBSD that haven't been released yet...

> Thoughts?

Signals + threads = pain.

Seriously, I think you can get unmasked children by calling fork() in
the main thread, but I'm not sure.  Maybe you could try that?

Cheers,
M.

-- 
  Need to Know is usually an interesting UK digest of things that
  happened last week or might happen next week. [...] This week,
  nothing happened, and we don't care.
                          -- NTK Know, 2000-12-29, http://www.ntk.net/



More information about the Python-list mailing list