[Bug libstdc++/80538] Probably unwanted thread yield for thread::sleep_for with < 1s

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80538

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to zulliger from comment #0)
> Which means that for values of __s.count() == 0, the current thread will
> always "yield" (according to my understanding, sleep(0) yields),

That's unspecified.

> just before
> the thread may actually fall asleep for some microseconds. Is this really
> the desired behaviour?

Any yield here is unspecified, so it's not _wrong_ but maybe suboptimal.

> Anyway, what's the desired effect of a thread::sleep_for(0.0)?

Calling this_thread::sleep_for(0s) returns immediately without ever reaching
__sleep_for. A positive value will cause the thread to sleep, which might
result in yielding one or more times.

>should the
> thread yield then? If not, then the code should look like this:
> 
>     if (__s.count() > 0) ::sleep(__s.count());
>     if (__ns.count() > 0)
>       {
>         long __us = __ns.count() / 1000;
>         if (__us == 0)
>           __us = 1;
>         ::usleep(__us);
>       }
> 
> shouldn't it?

I don't think it matters. A bigger problem is that the argument to sleep has
type unsigned and we pass it a value that might not representable in that type.
We also don't check for short sleeps. We should call it in a loop and check the
return value. That would lead to multiple calls to sleep, and so in general the
number of times we call sleep (and the number of times the thread yields) is
unpredictable.