search

riker-rs / riker

Easily build efficient, highly concurrent and resilient applications. An Actor Framework for Rust.
https://riker.rs
MIT License
1.02k stars 69 forks source link

Use Instant instead of SystemTime #42

Closed uazu closed 4 years ago

uazu commented 5 years ago

Instant is intended to be used for timers. SystemTime can go backwards, e.g. if the system clock is adjusted. If the clock goes backwards, then everything relying on a timer would stop working until time catches up again (e.g. hours/days later). See the docs in the std lib.

mkj commented 5 years ago

Instant makes sense for delay or interval values. What about schedule_at_time, I guess that kind of has to be real-world clock?

https://github.com/riker-rs/riker/blob/master/src/system/timer.rs#L128 looks like it needs a distinction between jobs using Instant jobs, and jobs using SystemTime.

uazu commented 5 years ago

Personally I'd run everything on Instant time. How many tools actually need to schedule things by wall clock time? Perhaps only cron, or personal assistant / scheduling type tools. Also since SystemTime can go backwards, there is no way to reliably trigger on a particular time being reached. So if you need to use wall clock time, either you estimate how long before SystemTime will reach the desired time, and wait for that in terms of Instant time, or else if you really care about noticing when SystemTime changes unexpectedly, you'd need to poll it at intervals. Those few cases can be handled in application code, since the application knows what tradeoffs it is happy with.

riemass commented 4 years ago

Please review the PR. I introduces Instant to timer. The call interface stays the same. One part I don't like so much is that by subtracting DateTime<Utc> types, std::time::duration::Duration is returned, and Instant uses the std::time::Duration for addition, so I had to convert to an integer type and back to Duration type. I could not find any other workaround. Should be safe enough.