> Evaluate Python code in a signal handler is really not a good idea!

I know, you're limited to async-safe functions, among other things :-)

> because of the GIL, I don't think that we can do better. But with the
> GIL of Python 3.3, the Python signal handler will be called "immediatly"
> before the next instruction, instead of having to wait something like
> 100 Python instructions (sys.getcheckinterval()). On this point, Python
> 3.3 is better than all previous versions.
>

Nice.

> Well, we can imagine to have an option/function to enable real time
> and/or in-order signals (e.g. using pipes).
>
> Can we call this mode "real time"? Real time means that we warranty a
> maximum response time.
>

Well, I think that we should either make this the default behaviour
(that's why I was asking whether it's possible on Windows), or not
implement it. Having two modes for signal handling is confusing.
But given that this behaviour has never been noticed before and that I
doubt that people needing real-time signals use Python (and
vice-versa), maybe we should just stick with the current
implementation, which is safe and simple (see Antoine's question, "Is
it a theoretical concern or does it affect real software?").
On the other hand, if it turns out to be interesting to some people,
I'd be happy to work on a patch.

>> By the way, to be pedantic, in the current code, wakeup_fd and
>> Handlers should be volatile, and tripped should be sig_atomic_t.
>
> Yes. Can you please write a patch for this?

Patch attached.