> 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.

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.
- the thread would have to be respawned after a fork()

> The C version is quite recent, and there's a school of thought that we
> should always provide fallback Python implementations.
> (also, arguably a Python implementation makes things easier to
> prototype, although I don't think it's the case for an RLock)

Hmmm, I'm not convinced by this argument in this specific case: since
the C version is now the default, is faster and more reliable, can't
we drop the Python version?