Signal should support arbitrary signals

[joshtriplett]

The Signal enum is missing the real-time signals, from SIGRTMIN to SIGRTMAX.

Handling these will be interesting, because glibc reserves the first two of them, and does so by changing its exposed value of SIGRTMIN.

I would suggest exposing the same SIGRTMIN that glibc does (34 rather than 32), and additionally exposing enum values for the two reserved signal numbers, with names that clearly indicate that they're reserved by libc.

That way, when people port from C to Rust, they won't get surprised by the difference.

[sunfishcode]

A complication is that glibc does not expose the values of SIGRTMIN or SIGRTMAX in its ABI. Even the number of signals it reserves is not exposed. The number of reserved signals has changed in the past and could theoretically change again in the future.

Perhaps we should make functions like kill_process unsafe. That way we could allow Signal to hold any SIGRTMIN+n signal and just say it's UB if you ever use a reserved signal value.

Another would be to make Signal::from_raw unsafe, and make it UB to construct a Signal with a reserved signal value.

[joshtriplett]

I think at this point it is safe to assume that the number of reserved signals won't change anymore; it has been the same since the move from libc5 to libc6, and there will almost certainly never be a libc7. If that did change, far too much would break.

If you prefer to not bake in that assumption, you could expose the real SIGRTMIN, and let applications handle avoiding the reserved signals.

Either way, I don't think you need to make the possibility of sending those signals any more unsafe than any other signal; sending any signal an application doesn't expect can cause problems. So if you want to make something unsafe, I would suggest kill_process rather than the creation of the signal number.

[sunfishcode]

I agree that it's unlikely that libc would claim new SIGRTMIN+n signals at this point, but I'd prefer to avoid claiming that space as our own if practical.

I think I've found a good way to approach this, so I've now filed #1292 which has:

• from_raw is now behind "use-libc-sigrt" feature and now supports SIGRTMIN+n values (safely).
• there's now a Signal::rt(n) constructor for constructing SIGRTMIN+n values, also enabled with "use-libc-sigrt"
• an unsafe from_raw_unchecked that returns Self
• etc.

Does that look like it'll work for your use cases?

[joshtriplett]

Having rt_min and rt_max, which depend on libc, does make sense.

However, I'd really like to be able to work with signals safely without introducing a dependency on libc.

Would you consider, as an alternative:

• Keeping the use-libc-sigrt feature, as you have now, with the current behavior, and
• Having a use-hardcoded-libc-sigrt feature on Linux, which hardcodes the current well-known values, and the name self-documents that the user is taking responsibility for the decision to hardcode them.

That way, it'd be possible for applications to either depend on libc or hardcode the libc6 ABI, and use safe code.

[sunfishcode]

Are you writing code which can know it isn't sharing a process with a libc? If so, we could add a safe pub fn sigrt(n: i32) -> Option<Signal> to the rustix::runtime module, that works in terms of linux_raw_sys::general::SIGRTMIN instead of libc's, so it would give you access to the whole range.

[joshtriplett]

Are you writing code which can know it isn't sharing a process with a libc?

Not necessarily, I'd just like to avoid calling into libc if not necessary.

If so, we could add a safe pub fn sigrt(n: i32) -> Option to the rustix::runtime module, that works in terms of linux_raw_sys::general::SIGRTMIN instead of libc's, so it would give you access to the whole range.

That would help, and I could live with that being in runtime.

[sunfishcode]

Some datapoints:

• musl reserves 3 signals
• Android's bionic reserves 10 signals and has added new ones recently
• linuxthreads reserved 3 signals
• glibc/NPTL today reserve 2, though apparently have a function for reserving more? It's not clear what that's for, but a quick code search found some random code using it....

None of these necessarily rules out using hardcoded values, but do mean it's worth considering alternatives before doing so.

I've now added a patch to #1292 adding rustix::runtime::sigrt, which constructs SIGRTMIN+n Signal values using the kernel SIGRTMIN value.