-
Notifications
You must be signed in to change notification settings - Fork 667
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
Add alarm #830
Add alarm #830
Conversation
bors r+ |
Build failed |
Travis failed because of a temporary network failure. Try again. bors r+ |
Timed out |
Bors timeout out, but the build passed. Does that mean it's ok to merge? |
The timeout was probably buildbot's fault. Buildbot has suddenly started to run much slower than it used to. There's probably some kind of problem with the VM host. We should just try again. However, you'll have to rebase to fix the conflict in CHANGELOG.md. |
@asomers This should be good to merge now. |
You'll need to rebase this to update the CHANGELOG now that 0.10.0 was released. |
done. |
In looking this over again I realized that this is another one of those functions that overloads the intneger range with different functionality. I'm not a fan of this and generally try to alter the API to avoid this. For example in this case there are really two functions that should exist, one to set an alarm to a given number of seconds and another to clear any existing alarm. I'd much prefer using an |
@surrus I've change the argument to |
src/unistd.rs
Outdated
/// use nix::unistd::{alarm, SetAlarm}; | ||
/// | ||
/// // Set an alarm for 60 seconds from now. | ||
/// alarm(SetAlarm::Set(60)); |
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.
I forgot that you need to specify the enum name when you initialize a variant of it, so this doesn't read as well as I hoped. I was originally going to suggest that instead of an enum we split alarm
into two functions, alarm_set(c_uint)
and alarm_cancel()
. I'm now thinking that would be a more ergonomic API. The only downside to that is discoverability, but I think the docs will be enough there. And if a user searches the docs for "alarm", I'd expect them to find these two functions and be able to understand their usage.
@Thomasdezeeuw What do you think?
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.
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.
I didn't realize this was a spin off of an earlier PR, sorry about that. Read through it quickly and it provides a little more context. I didn't get a chance to respond early in the last PR, but I think if we have functions that start with alarm_
it's a nice API. So let's go ahead and switch to that type of API. @asomers Care to chime in 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.
I'm also actually thinking rather than name these functions that are split off from a single libc
function by prefixing them within their function name, instead prefix them within a module. So you'd have alarm::set(c_uint)
and alarm::cancel()
. That should really help with the end-user documentation. We're already doing this with ptrace
.
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.
Actually, I like the module idea. It's less verbose than using enums, but still Rustier than using alarm_set
and alarm_cancel
.
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.
I've put the function into their own module and also expanded the documentation.
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.
Awesome work with the examples and the tests, I really like how this is shaping up! Some small grammatical fixes and a couple of API questions to finish up.
src/unistd.rs
Outdated
//! | ||
//! # Examples | ||
//! | ||
//! Canceling an alarm. |
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.
: instead of .
src/unistd.rs
Outdated
//! | ||
//! # Notes | ||
//! | ||
//! Scheduling an alarm will trigger a `SIGALRM` signal when the the time |
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.
"the the"
src/unistd.rs
Outdated
//! | ||
//! See also [alarm](http://pubs.opengroup.org/onlinepubs/9699919799/functions/alarm.html). | ||
//! | ||
//! # Notes |
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.
I would just remove this "Notes" header
src/unistd.rs
Outdated
//! assert_eq!(alarm::cancel(), 60); | ||
//! ``` | ||
//! | ||
//! Scheduling an alarm and waiting for the signal. |
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.
: instead of .
src/unistd.rs
Outdated
/// Schedule an alarm signal. | ||
/// | ||
/// This will cause the system to generate a `SIGALRM` signal for the | ||
/// process after the number of `secs` have elapsed. |
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.
"after the specified number"
src/unistd.rs
Outdated
/// This will cause the system to generate a `SIGALRM` signal for the | ||
/// process after the number of `secs` have elapsed. | ||
/// | ||
/// Returns the leftover time of a previously set alarm, or `0` if no alarm |
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.
Do you think an enum return type would be more helpful here than just an int?
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.
I was thinking about that as well, maybe Option<libc::c_uint>
with 0 mapped to None
.
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.
I think using the Option
type here makes a lot of sense!
src/unistd.rs
Outdated
/// | ||
/// Returns the leftover time of a previously set alarm, or `0` if no alarm | ||
/// was set. | ||
pub fn set(secs: libc::c_uint) -> libc::c_uint { |
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.
Should we check for 0 in the input argument with an assertion? I think if people are doing that they should really be using cancel
instead of set
.
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.
I could add a simple assertion.
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.
What about this:
assert!(secs != 0, "passing 0 to `alarm::set` is not allowed, to cancel an alarm use `alarm::cancel`");
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.
Sure, that'd be fine.
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.
Minor doc edits then it LGTM.
src/unistd.rs
Outdated
/// This will cause the system to generate a `SIGALRM` signal for the | ||
/// process after the specified number of seconds have elapsed. | ||
/// | ||
/// Returns the leftover time of a previously set alarm, or `0` if no alarm |
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.
Change to "Returns the leftover time of a previously set alarm if there was one" since now this returns an Option
.
src/unistd.rs
Outdated
|
||
/// Cancel an previously set alarm signal. | ||
/// | ||
/// Returns the leftover time of a previously set alarm, or 0 if no alarm |
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.
Same as the above.
src/unistd.rs
Outdated
pub mod alarm { | ||
//! Alarm signal scheduling. | ||
//! | ||
//! See also [alarm](http://pubs.opengroup.org/onlinepubs/9699919799/functions/alarm.html). |
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.
Change the link to "alarm(2)" and move this into its own "# References" section after the Examples section.
CHANGELOG.md
Outdated
@@ -7,6 +7,9 @@ This project adheres to [Semantic Versioning](http://semver.org/). | |||
|
|||
### Added | |||
|
|||
- Added `alarm`. |
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.
Just make this one line.
LGTM. Please squash into a single commit and then we'll merge. @asomers Care to take another gander? |
This module has two functions; set: set an alarm, and cancel: cancels a previously set alarm.
@Susurrus done. |
bors r+ |
Fixed #828.