[LLVMbugs] [Bug 13721] New: sleep_for(std::chrono::duration<T>::max()) does not sleep at all for (T > uint32_t)

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=13721

             Bug #: 13721
           Summary: sleep_for(std::chrono::duration<T>::max()) does not
                    sleep at all for (T > uint32_t)
           Product: libc++
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: arthur.j.odwyer at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


As of https://llvm.org/svn/llvm-project/libcxx/trunk@162648 libc++'s <chrono>
header contains the following template definition:

    template <class _Rep, class _Period>
    void
    sleep_for(const chrono::duration<_Rep, _Period>& __d)
    {
        using namespace chrono;
        nanoseconds __ns = duration_cast<nanoseconds>(__d);
        if (__ns < __d)
            ++__ns;
        sleep_for(__ns);
    }

This has wrong behavior (even undefined behavior!) if the conversion of __d to
nanoseconds overflows the type _Rep. I don't see any language in the C++11
standard that permits misbehavior for large values.

For example:

    #include <chrono>
    #include <thread>
    int main() {
        std::this_thread::sleep_for(std::chrono::milliseconds::max());
    }

This seems like a nice idiom to indicate "sleep forever", but in fact this
program returns immediately! Even worse, from the user's point of view:

    while (true)
      std::this_thread::sleep_for(std::chrono::seconds::max());

This loop is intended as a future-proof "sleep forever", but libc++ turns it
into a "busy-wait forever". The programmer's attempt to relinquish the CPU gets
turned into the exact opposite!

Incidentally, is there a better (clearer and/or more portable to libc++) idiom
to indicate "sleep forever", in cases where we have nothing else to do but
can't afford to kill ourselves? (Perhaps some other thread holds references to
objects on our stack.) My only other idea is "create a private condition
variable and wait on it", but IMHO that fails Occam's Razor.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.