-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Enhance / redesign the time module #2153
Comments
http://www.c-plusplus.de/forum/43364 (win32 nanosleep) |
I don't know if we want to encourage sleep functions that actually put the thread to sleep (though obviously they are useful for some purposes). Sleeping should generally just block the task and let the runtime continue to schedule other tasks. Timers is one of the first things I was planning on implementing with libuv. |
Ah, I didn't consider doing timers via libuv. Just thought that we should have a high resolution sleep function that matches to the timespec type. I was thinking about all things in the context of recv with timeout. Keeping this in mind, whatever sleep/timer function will be used maybe should go into the runtime for consistency of implementation. Regarding a blocking sleep, a frequent use case I had in golang was in tasks that are locked onto a fixed thread due to C interop requirements (libzeromq bindings). |
Nominating to change milestone to feature-complete. |
time module is kinda ad-hoc at this point, needs more principled (re)design |
accepted for backwards-compatible milestone |
This implements `Add` and `Sub` for `Timespec`, which enables `Timespec` to be used as a time span. For example: ```rust let begin = get_time(); // Do some stuff. let end = get_time(); let delta = end - begin; println!("Doing stuff took {}.{:09d} seconds.", delta.sec, delta.nsec); ``` This resolves one of the points mentioned in #2153.
This should probably be moved to https://github.com/rust-lang/time, unless we want to add any of these features to |
Agreed. |
with permissive-provenance set, we already treat ptr::invalid correctly (same for strict provenance, but there it is not surprising)
The text was updated successfully, but these errors were encountered: