Added clock_gettime, clock_getres, clock_settime, clock_getcpuclockid #1281
Conversation
|
@asomers @kamalmarhubi @posborne Friendly ping for code review, thanks! |
src/time.rs
Outdated
| } | ||
|
|
||
| /// Returns time on the clock id | ||
| pub fn time(self) -> Result<TimeSpec> { |
There was a problem hiding this comment.
Since this method is basically the same as std::time::Instant::now, it would be good if the API could be similar. Do you agree? The time method could be renamed now, and we could add convertability between TimeSpec and Instant.
There was a problem hiding this comment.
Agreed. Wasn't sure if now() makes sense for pid-based clocks, but I guess it sort of does as we get the time on the pid-based clock at the current moment. I'll update the PR.
There was a problem hiding this comment.
Looking more, it seems like std::time::Instant is pretty limited in its usage and seems to be designed to just get the current monotonically increasing time, rather than all purpose type to represent an arbitrary point in time (i.e. the only way to construct std::time::Instant is to call Instant::now()).
The other problem is that I don't think it makes sense to convert the time process has been running on CPU to a particular point in time since unix epoch. Looking on C timespec documentation I think TimeSpec is closer to std::time::Duration rather than std::time::Instant (or even std::time::SystemTime), as it represents the interval rather than particular point in time.
If that makes sense, I can add convertability between TimeSpec and Duration.
There was a problem hiding this comment.
Hm, good point. I agree. Duration is more appropriate.
|
Looks like with a recent change to libc to change some functions from unsafe to safe on linux platform, the usage of those function is now broken across platforms. I'll look into fixing those, probably the best way is to make functions safe on other platforms as well... |
|
PR #1294 will fix the unused unsafe warnings. However, I like your change better, because it's more finely tuned. Would you consider opening a separate PR just for those? |
|
Looks like that PR is updated to be more finely tuned, so I guess a separate PR is no longer needed. I'll merge and update my changes once that PR is merged. On a side note, once rust-lang/libc#1891 gets into new release the |
|
Clicked the wrong button :/ |
|
Sure, but that probably extends only by 1 version, as this change already bumps up the |
|
You'll have to rebase; don't merge master into your branch. |
xonatius
force-pushed
the
issue_1275
branch
from
c52c408
to
af02db6
Compare
|
Done, let me know if you prefer me to squash changes into a single commit. |
| /// Newtype pattern around `clockid_t` (which is just alias). It pervents bugs caused by | ||
| /// accidentally passing wrong value. | ||
| #[derive(Debug, Copy, Clone, Eq, PartialEq, Ord, PartialOrd, Hash)] | ||
| pub struct ClockId(clockid_t); |
There was a problem hiding this comment.
The enum won't work for clockid_t returned by clock_getcpuclockid, that's why I had to go with struct.
There was a problem hiding this comment.
You're worried that the OS may add a new clockid that Nix doesn't know about? Ok, that's a fair reason.
|
LGTM! Just squash the commits now. |
xonatius
force-pushed
the
issue_1275
branch
from
e8cfe96
to
91effec
Compare
|
Done! |
|
Build succeeded: |
Picked up #1100 and added
clock_getcpuclockidcall as well. Credits to @kevinwern for the initial version.https://www.man7.org/linux/man-pages/man2/clock_gettime.2.html
https://www.man7.org/linux/man-pages/man3/clock_getcpuclockid.3.html
Closes #1275