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

Add alarm #830

Merged
merged 1 commit into from
Feb 3, 2018
Merged

Add alarm #830

merged 1 commit into from
Feb 3, 2018

Conversation

Thomasdezeeuw
Copy link
Contributor

Fixed #828.

@asomers
Copy link
Member

asomers commented Jan 8, 2018

bors r+

bors bot added a commit that referenced this pull request Jan 8, 2018
830: Add alarm r=asomers a=Thomasdezeeuw

Fixed #828.
@bors
Copy link
Contributor

bors bot commented Jan 8, 2018

Build failed

@asomers
Copy link
Member

asomers commented Jan 8, 2018

Travis failed because of a temporary network failure. Try again.

bors r+

bors bot added a commit that referenced this pull request Jan 8, 2018
830: Add alarm r=asomers a=Thomasdezeeuw

Fixed #828.
@bors
Copy link
Contributor

bors bot commented Jan 8, 2018

Timed out

@Thomasdezeeuw
Copy link
Contributor Author

Bors timeout out, but the build passed. Does that mean it's ok to merge?

@asomers
Copy link
Member

asomers commented Jan 11, 2018

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.

@Thomasdezeeuw
Copy link
Contributor Author

@asomers This should be good to merge now.

@Susurrus
Copy link
Contributor

You'll need to rebase this to update the CHANGELOG now that 0.10.0 was released.

@Thomasdezeeuw
Copy link
Contributor Author

done.

@Susurrus
Copy link
Contributor

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 enum datatype for the arguments so you'd do something like alarm(Seconds(15)) to set the alarm and alarm(Clear) to clear it. That reads better to me than alarm(15) and alarm(0).

@Thomasdezeeuw
Copy link
Contributor Author

@surrus I've change the argument to SetAlarm, with the variants Cancel and Set to be more inline with the documentation on Opengroup (they use cancel rather then clear).

src/unistd.rs Outdated
/// use nix::unistd::{alarm, SetAlarm};
///
/// // Set an alarm for 60 seconds from now.
/// alarm(SetAlarm::Set(60));
Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my original pr (#828) I had two those function exactly, but @asomers was against that.

Copy link
Contributor

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?

Copy link
Contributor

@Susurrus Susurrus Jan 31, 2018

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.

Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Contributor

@Susurrus Susurrus left a 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.
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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.
Copy link
Contributor

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.
Copy link
Contributor

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
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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 {
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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`");

Copy link
Contributor

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.

Copy link
Contributor

@Susurrus Susurrus left a 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
Copy link
Contributor

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
Copy link
Contributor

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).
Copy link
Contributor

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`.
Copy link
Contributor

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.

@Susurrus
Copy link
Contributor

Susurrus commented Feb 2, 2018

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.
@Thomasdezeeuw
Copy link
Contributor Author

@Susurrus done.

@asomers
Copy link
Member

asomers commented Feb 3, 2018

bors r+

bors bot added a commit that referenced this pull request Feb 3, 2018
830: Add alarm r=asomers a=Thomasdezeeuw

Fixed #828.
@bors
Copy link
Contributor

bors bot commented Feb 3, 2018

@bors bors bot merged commit fecf484 into nix-rust:master Feb 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants