> > That sounds like a good solution in the middle-term. Are there any
> > drawbacks? (apart from launching a thread)
> 
> Just to be clear: the approach I was suggesting is to have a resident
> thread dedicated to signal management, not to spawn a new one when
> needed. Another advantage is that we could mask signals in all threads
> except this one, and have a consistent cross-platform behavior with
> respect to signals+threads.

Hmm, but that would break single-threaded programs which expect their
select() (or other) to return EINTR when a signal is received (which is
a perfectly valid expectation in that case).

> However I see two drawbacks:
> - it seems that we want to allow building Python without threads
> support. In that case, this wouldn't work, or we would need the
> current implementation as a fallback, but this would complicate the
> code somewhat.

I don't know if that's still useful to build Python without threads. I
would expect most platforms to have a compatible threads implementation
(and Python probably can't run on very small embedded platforms).
Perhaps you can ask on python-dev.