> 1. On FreeBSD, we must assume that every blocking system call, in
> *every thread*, can be interrupted, and we need to catch EINTR.

That's true for every Unix. Every blocking syscall can return EINTR, and there are may non restartable syscalls. Writting code which depends on
a specific OS behavior, or whether the code is run from the main thread,
is broken.

>  2. On FreeBSD, we cannot block indefinitely in the main thread and
> expect to handle signals. This means that indefinite selects are not
> possible if we want to handle signals, and, perhaps more perversely,
> signal.pause() cannot be reliably used in the main thread.

The proper way to do so, in Python as in C, is to use pthread_sigmask
(http://docs.python.org/dev/library/signal.html#signal.pthread_sigmask)
- thanks to Victor. Just block all signals by default, and create a thread dedicated to signals management (that's the approach used by Java). You could also play some nice tricks with set_wakeup_fd (http://docs.python.org/dev/library/signal.html#signal.set_wakeup_fd).

> * Block all *asynchronous* signals in user threads.

What if some code expects to receive a signal from a thread other than
the main thread?

> * Unblock all signals after a fork() in a thread, since the thread is
> now the main thread.

What if a signal is delivered between fork() and unblock?

Really, signals and threads don't mix well (kinda like fork() and threads), so I don't think we can expect to fix this in Python. There's no free lunch, every design will chose will break existing code, or won't work as expected on a platform. The best we can do is to keep a sensitive default behavior (i.e. the one chosen by the OS designers), and offer APIs allowing the user to fine-tune the behavior according to its needs.

We've fixed many bugs pertaining to signals and threads during the last months, and we've gained a couple useful APIs to deal with signals and threads (pthread_sigmask(), sigwait(), etc).

I'd suggest to close this.