-
Notifications
You must be signed in to change notification settings - Fork 666
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
Implement nix wrapper for libc::signal #817
Conversation
@asomers, could you review this again when you have some time? No rush - and happy holidays! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add something to the doc comment explaining that signal
should only be used following another call to signal
or if the current handler is the default. The return value of signal
is undefined after setting the handler with sigaction
.
This looks good; it just needs a squash. |
src/sys/signal.rs
Outdated
/// | ||
/// Returns [`Error::UnsupportedOperation`] if `handler` is | ||
/// [`SigAction`][SigActionStruct]. Use [`sigaction`][SigActionFn] instead. | ||
/// `signal` also returns any error from `libc::signal`. such as when an attempt |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you put a blank line above this one? These should be separate paragraphs since they're distinct comments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please also rebase this and move the CHANGELOG to the UNRELEASED section.
I'm also not the biggest fan of the example since it's not a realistic one, it looks more like a test. Can you turn it into a more realistic example? Like something a user might actually write? If not, let's actually remove it. @asomers any ideas on a better example here? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For a more realistic example, you could just remove the assert
and remove the second line that sets the signal handler back to the default. Using signal
to ignore SIGINT
is a pretty realistic use case.
The only other realistic use case is probably to set a simple signal handler that sets a flag variable.
@rgardner You planning to come back to this? We'd like to get this merged if you're willing. Otherwise I'd like to close this PR. |
Yes, I too would like to get this merged. I'm unsure of exactly what to write in the safety section, I mostly chose unsafe out of inertia with the existing I'm open to suggestions for the safety section. Otherwise, I don't think this should block the PR, someone can add it in a follow up. |
This needs the commits to be squashed to one commit, a rebase onto the latest master, and a re-run through CI to pass before it can be merged. Otherwise it looks good to me. @asomers any comments on the Safety section? |
@asomers - friendly ping, could you take another look at this PR when you get a chance? Thank you for all the feedback. |
Sorry that this fell off of my radar, @rgardner . It LGTM now. But it will need a rebase before it can be merged. Be careful when rebasing CHANGELOG to get your entry in the right section. |
No worries, fell off my radar too. I've rebased and ensured that the CHANGELOG entry is at the bottom of the Added section under [Unreleased]. |
bors r+ |
Build succeeded
|
This implements
nix::sys::signal::signal
and adds corresponding documentation and tests.Closes #476