Crate sched_clock

Representations of time needed by task scheduling algorithms

For the purpose of task scheduling, we represent time as a 64-bit signed count of nanoseconds before or after some reference (such as system startup, scheduler startup...). This seems appropriate as of 2019 because:

• CPU frequencies are currently capped at a few GHz by thermal limits, and no known physics can help us evade those limits, so a nanosecond is likely to remain a few CPU cycles for a while. Which is enough precision for any practical scheduling purpose, because the scheduler itself will take more time to execute / have more jitter than that.
• 2^63 nanoseconds is a bit less than 300 years, and as of 2019 humans are not capable of planning work several centuries ahead or work that will take several centuries to complete. Not to mention that this code will likely become obsolete on a much smaller timescale, of course.

We're largely reimplementing std::time::{Duration, Instant} here, because while we like its overall API design...

• We do not need the huge dynamic range of std::time (~600 years is enough for us). And we expect to manipulate time often and under tight performance constraints, so we need all the extra processing speed and storage savings that we can get.
• We want freedom to switch to OS- or hardware-provided facilities that give us either more correctness, more speed, or both, whereas the standard library puts portability and simplicity above everything else.
• We find signed durations and instants to be useful and worth supporting.

Re-exports

pub use crate::clocks::Clock;

pub use crate::clocks::DefaultClock;

Modules

clocks	Clocks providing Instants to this library
prelude	Standard imports to make this crate easiest to use

Structs

Duration	Algebraic (signed) durations
Instant	Points in time