timer::sleep sets any Duration < 1ms to 0. The problem is that it does this happens silently, resulting in confusion. Is it feasible to provide a compile-time warning (or failure) in such cases?
Currently, sleep does not accept a duration that is less than a millisecond, as shown by your post. If it is less, than it does not activate.
However, it should be documented that timer::sleep only sleeps in terms of milliseconds. (relevant doc page)
You can not provide a compile time warning in non-trivial code, because the time could be submitted by a user.
I do not think it is feasible to panic in this case because it seems like it is doing what it should. If you want to fail in this case, you should check it yourself.
Why not have timer::sleep round its argument up to the next full millisecond? (Or whatever unit the underlying syscall deals in.)
1 Like
I think this behavior is too surprising, and a panic should happen. This would force the user to handle it, instead of just failing silently as it does.
I don’t know which of the two options is less bad.
+1 for explicit panic. I feel like rounding behavior is too easy to not
know about, and it would make code like sleep(Duration::microseconds(1))
totally misleading.
Maybe having it return a Result<(), E> instead would be a solution? It would make it both easy and explicit to ignore.
I think trying to use sleeps to explicitly order operations is fundamentally broken code: Other system events could intervene and you might not get the ordering you want anyways!
That said, if the semantics of sleep is that it sleeps for at least that amount of time, the correct behaviour is to round up, not down.
Panicing is absurd: If you’re calculating the value somehow and it happens to be smallish, why shouldn’t that work? It may sleep a little longer (with the propsed rounding up), but that’s always true. This is no real time system.
Rounding up seems to be the way to go.
Rounding up seems commonly used. POSIX defines it for the various sleeps. e.g., http://linux.die.net/man/2/nanosleep specifies:
"If the interval specified in req is not an exact multiple of the granularity underlying clock (see time(7)), then the interval will be rounded up to the next multiple."
It seems to me this will be the least surprising. I would imagine if Rust were to be used for real time, there would need to be lots of additional API to handle that.
+1 for rounding up.
Let me also point out that anything like sleep(1 ms) should be designed to “sleep for at least 1 ms” because no OS can guarantee to wake up the thread when exactly 1.0000 ms has just passed when, say, the system is very busy (it’s really a shame that Win32 API doesn’t follow this design principle…)
Rounding up would be the better behavior.
Please remember that Rust must be platform-neutral. There are platforms that have a higher sleep resolution, now and potentially in the future. For example, Windows uses a sleep interval of 100ns in its APIs, even if the underlying hardware uses a different granularity.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.