Dunno.

> The patch is not completely safe.

Yeah it will not work without atomic ops.
Unfortunately the C standart seems to go into a direction
noone understands - as if a atomic_compare_and_swap() would
not suffice!  Do you know any machine language which reflects
what that standart draft describes?  I don't.

The NSIG detection of Modules/signalmodule.c uses 64 as a fallback.
32 seems to be more reasonable.
And you test against it instead of RTMAX in the patch.
(signalmodule.c also exports Python constants RTMIN and RTMAX
even though the standart explicitely allows these values to
be non-constants;
 http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html; last time i've done anything on signals - in 2005 - that was
used nowhere - Linux, FreeBSD - though.)

Often there is a huge whole in between NSIG and RTMIN, but
struct Handlers is 8 or 12 bytes (unless the compiler does the
alignment - ouuh), so 32 unused members in Handlers[] will not
cost the world anyway; on Mac OS X (no RTSIG support?!? ;)
Python is at least 6 megabytes of memory anyway.

And does anyone actually know why the last time i looked after this
(on Linux, then) realtime signals had a default action EQ SIGABRT?
Armchair crouchers...