[Mono-list] Handling SIGRT* signals

[Jonathan Pryor]

On Wed, 2008-12-10 at 17:33 +0000, tim.jenks at realtimeworlds.com wrote:
> I have been looking over the UnixSignal class hoping to Wait on a
> SIGRT signal raised by a native library. Unfortunately, I can only
> create UnixSignal instances to handle signals defined in the Signum
> enumerator and not Signals >= SIGRTMIN.
>
> Is there a way to handle SIGRT* signals in Mono currently?

It isn't currently supported because it's not trivial to support.  It's
not difficult either, but I haven't carved out enough time to support it
yet.

The fundamental problem is that Signum CANNOT hold a realtime signal.
This is so because:

1. Signum contains platform-independent values.  Consequently, any
Signum values need to be mapped at runtime to the appropriate
platform-specific values, but...

2. There is not a concrete set of realtime signals.

All POSIX ensures is that the lowest realtime signal is SIGRTMIN, the
highest signal is SIGRTMAX, and that SIGRTMAX-SIGRTMIN >= 8 (according
to signal(7)).

So we could provide a Signum value for SIGRTMIN, but I don't think it
would be sensible to support SIGRTMAX or any of the values betwen
SIGRTMIN & SIGRTMAX.

So what's instead needed is an alternate mechanism for realtime signals,
e.g. add a new type:

        public struct RealTimeSignal {
          public RealTimeSignal (int offset);
          public int Offset {get;}
        }

such that `new RealTimeSignal(N)' is equivalent to `SIGRTMIN+N'.  Then,
we need only overload members that accept Signum such as
Stdlib.SetSignalAction() and the UnixSignal constructor to accept
RealTimeSignal instances in addition to Signum values.

Then lots of plumbing work to ensure that The Right Thing happens, as
currently the UnixSignal constructor/etc. go through the mapping code to
convert Signum values to their actual runtime values, while for
RealTimeSignals we'd need to grab the runtime value of SIGRTMIN and add
Offset to it, with an additional runtime check that
SIGRTMIN + Offset <= SIGRTMAX.

That said, it shouldn't be too difficult to implement this, but I'm
sufficiently swamped that I won't get to it anytime soon, so if you'd
like to cook up a patch I'd love to review it...

 - Jon