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.