Closed workingjubilee closed 2 weeks ago
First found on espidf:
cc @ivmarkov @mabezdev @SergioGasquez
cc @stlankes @mkroening
First found on espidf:
cc @ivmarkov @MabezDev @SergioGasquez
@workingjubilee
Agreed - problem is clear and I'll fix shortly - thanks for noticing!
An interesting question here is whether it is allowed - in thread:sleep
- to busy-wait for sleeping? Because this is exactly what would happen on the ESP IDF if the supplied duration is less than 10ms (milliseconds) - i.e. the FreeRTOS sys-tick. Given that the thread:sleep
documentation is silent in this regard, I suggest to keep the current behavior (i.e. busy-waiting for durations < 10ms) as that allows callers of thread::sleep
to "at least do some sleep - busy-looping or not".
Note that this is not the only problem that espidf poses with respect to its std implementation: https://github.com/rust-lang/rust/issues/129136
I don't think this is a problem on the ESP IDF, as it does not support POSIX signals in the first place. Or processes thereof.
Yes, I believe busy-waiting is a valid implementation of sleep, and especially in particular, if we were to have a hypothetical fn sleep_can_sleep_for_this_long(dur: Duration) -> bool
that returned false
if the platform didn't have an actual syscall for sleeping for that long, I would expect busy-waiting to be on the other side of the if/else almost every single time.
Multiple targets currently use
Duration::as_micros
to implement conversion from a Duration to a value in microseconds. However,thread::sleep
currently reads as so:Up. Note this Playground which means
Duration::as_micros
is not a valid implementation of this spec.Note that this is not the only problem that espidf poses with respect to its std implementation: https://github.com/rust-lang/rust/issues/129136
Meta
rustc --version --verbose
: