[Mono-bugs] [Bug 458043] UnixSignal unable to handle SIGRT* signals

[bugzilla_noreply at novell.com]

https://bugzilla.novell.com/show_bug.cgi?id=458043

User jpryor at novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=458043#c2


Jonathan Pryor <jpryor at novell.com> changed:

           What    |Removed                                         |Added
----------------------------------------------------------------------------
                 CC|                                                |jpryor at novell.com




--- Comment #2 from Jonathan Pryor <jpryor at novell.com>  2008-12-10 12:04:19 MST ---
No, because the number of realtime signals is platform-dependent.  The only
thing known for sure is that you can specify any value between SIGRTMIN and
SIGRTMAX, but the _range_ SIGRTMAX-SIGRTMIN is unspecified and can vary.

(No idea how much it varies in practice, but it can, which is the point.)

Thus, it shouldn't be added to the Signum enumerator.

Furthermore, it's been determined that Stdlib.signal() is horribly broken 99%
of the time -- the only time it's safe to use is if you provide Stdlib.SIG_DFL,
or Stdlib.SIG_IGN as the handler function, as it is NOT safe for arbitrary
methods to be provided to Stdlib.signal().

(Which is why Stdlib.signal() is [Obsolete], with the suggestion that
Stdlib.SetSignalAction() be used instead.)

Which leaves the question: from what places would you like to use realtime
signals?

I can think of only three places: UnixSignal constructor,
Stdlib.SetSignalAction(), Stdlib.raise().  For all three, we can support
realtime signals by instead adding an overload for another type, e.g.:

  struct RealTimeSignum {
    int offset;
    public RealTimeSignum (int offset) {this.offset = offset;}
  }

This would allow using `new RealTimeSignum(N)` as an equivalent to SIGRTMIN+N.

Internally, Stdlib & UnixSignal could do the work of translating RealTimeSignum
instances into actual values based on the runtime value of SIGRTMIN, so
everything is kosher.

That's the basic idea, anyway, but I have no concrete plans to implement this. 
Additional feedback/patches welcome. :-)


-- 
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.