Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Realtime signals #495

Open
SdNssr opened this issue Jan 7, 2017 · 4 comments
Open

Realtime signals #495

SdNssr opened this issue Jan 7, 2017 · 4 comments

Comments

@SdNssr
Copy link

SdNssr commented Jan 7, 2017

Realtime signals seem to be missing from nix::sys::signal::Signal, and quite a few functions seem to panic on receiving realtime signals:

  • nix::sys::signal::SigSet::wait
  • nix::sys::wait::waitpid (when the child died because of a realtime signal)
  • and probably many others that I haven't yet used

So is this something that won't be supported, or is it just incomplete?

@fiveop
Copy link
Contributor

fiveop commented Jan 10, 2017

It is just incomplete. Feel free to add them. You might need to add the constants to libc first.

@Susurrus
Copy link
Contributor

Susurrus commented Jun 5, 2017

@SdNssr Any interest in filing a PR for this functionality?

@SdNssr
Copy link
Author

SdNssr commented Jul 8, 2017

No, not really.

@ObsidianMinor
Copy link

I want to take a shot at this. Only thing I see being an issue is how much of the existing API we want to keep.

If we want to keep the existing Signal type (because conversions to and from strings is nice), then I'd propose new types RtSignal and Signum.

RtSignal would be used to define new real-time signal values, with the function RtSignal::new(i32) being used to create the values, offset from SIGRTMIN. So RtSignal::new(0) would be the minimum value, RtSignal::new(1) would be SIGRTMIN() + 1, etc. This would return an optional value and can't be converted to a string except via debug impl.

Signum would take the place of most usage of Signal, it being a less typed variant that can represent a RtSignal or Signal value. SigSet's API would be based on Signum, accepting and returning instances of the type. You can attempt to unwrap an RtSignal or a Signal value from a Signum, for instance, for converting to a string, but functions wouldn't be defined on it.

Because Signum would be the primary type being used by SigSet, it would have it's own set of associated constants that correspond to the libc constants. These would be re-exported in place of the Signal enumerants. This is because I'm assuming that most people are using the Signal re-exported values for pattern matching on the result of SigSet::wait, so this would be the last painful upgrade path.

Alternatively, we rewrite the whole Signal type. We keep FromStr, but nothing can be converted into a real-time signal. as_str becomes something like try_as_str, which returns an optional value, none when a real-time signal is the value. AsRef<str> is removed, fmt::Display is removed, and SignalIterator is adjusted to iterate all valid real-time signal values as well.

Thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants