> It's not the only shortage with the current implementation regarding
> (real-time) signals. Another one is that they're delivered
> out-of-order (lowest-numbered signal first),

Oh yes, it can be a problem.

> and the most important one - especially for real-time signals - is
> that the handlers are executed synchronously, when Py_CheckSignals()
> is called.

Evaluate Python code in a signal handler is really not a good idea! And
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.

> While we can't do much about the the later, there's at least a way to
> handle the other issues, a small variant of the self-pipe trick:
> (...)
> drawbacks:
> - might be a bit slower, because of the read syscall
> - consumes 2 FDs

Consume 2 FDs can be surprising. We cannot do that by default (just to
have in-order or real time signals).

> - have to reinit the pipe on fork

Oh yes, it can be a problem.

> - does Windows have pipe/read/write?

Do you really think that Windows supports real time signals? :) Windows
has pipes: see the Connection object of the multiprocessing module
(Antoine is working on this topic). But I don't remember if they can be
used as POSIX files (using file descriptors).

> - maybe overkill
>
> But I'm really not sure that fixing this is worth it...

It looks like your reimplements the whole signal machinery between the
kernel and the application... But anyway, we need something between the
C signal handler and the Python signal handler (because we cannot
execute Python code in a C signal handler).

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.

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