Fix thread::sleep Duration-handling for ESP-IDF

[ivmarkov]

Addresses the ESP-IDF specific aspect of #129212

A short summary of the problems addressed by this PR:

================================================

1. Problem 1 - the current implementation of std::thread::sleep does not properly round up the passed Duration

As per the documentation of std::thread::sleep, the implementation should sleep at least for the provided duration, but not less. Since the minimum supported resolution of the usleep syscall which is used with ESP-IDF is one microsecond, this means that we need to round-up any sub-microsecond nanos to one microsecond. Moreover, in the edge case where the user had passed a duration of < 1000 nanos (i.e. less than one microsecond), the current implementation will not sleep at all.

This is addressed by this PR.

2. Problem 2 - the implementation of usleep on the ESP-IDF can overflow if the passed number of microseconds is >= u32::MAX - 1_000_000

This is also addressed by this PR.

Extra details for Problem 2:

u32::MAX - 1_000_000 is chosen to accommodate for the longest possible systick on the ESP IDF which is 1000ms.

The systick duration is selected when compiling the ESP IDF FreeRTOS task scheduler itself, so we can't know it from within STD. The default systick duration is 10ms, and might be lowered down to 1ms. (Making it longer I have never seen, but in theory it can go up to a 1000ms max, even if obviously a one second systick is unrealistic - but we are paranoid in the PR.)

While the overflow is reported upstream in the ESP IDF repo¹, I still believe we should workaround it in the Rust wrappers as well, because it might take time until it is fixed, and they might not fix it for all released ESP IDF versions.

For big durations, rather than calling usleep repeatedly on the ESP-IDF in chunks of u32::MAX - 1_000_000us, it might make sense to call instead with 1_000_000us (one second) as this is the max period that seems to be agreed upon as a safe max period in the usleep POSIX spec. On the other hand, that might introduce less precision (as we need to call more times usleep in a loop) and, we would be fighting a theoretical problem only, as I have big doubts the ESP IDF will stop supporting durations higher than 1_000_000us - ever - because of backwards compatibility with code which already calls usleep on the ESP IDF with bigger durations.

Footnotes

1. https://github.com/espressif/esp-idf/issues/14390 ↩

[rustbot]

r? @tgross35

rustbot has assigned @tgross35.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[ivmarkov]

r? @workingjubilee

[ivmarkov]

@workingjubilee Sorry for the ping - this is ready for review now.

[workingjubilee]

Can the PR note be more descriptive? We spent several minutes in the recent T-libs-api evaluation of the process of something going horribly wrong on discovering various forms of "yeah no one clicks through issue numbers to see the context" are true. While I hope this won't have anything like that be related to it, best not to get in the habit. It is better to copy my issue's entire description than leave it as a number.

[ivmarkov]

Can the PR note be more descriptive? We spent several minutes in the recent T-libs-api evaluation of the process of something going horribly wrong on discovering various forms of "yeah no one clicks through issue numbers to see the context" are true. While I hope this won't have anything like that be related to it, best not to get in the habit. It is better to copy my issue's entire description than leave it as a number.

No prob! I've updated the PR description with all the details. Let me know if you want me to correct / provide extra details.

[workingjubilee]

Very thorough! Thank you.

@bors r+ rollup

[bors]

📌 Commit 1faccba has been approved by workingjubilee

It is now in the queue for this repository.