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

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Tue Aug 28 14:59:12 PDT 2012


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

Howard Hinnant <hhinnant at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #1 from Howard Hinnant <hhinnant at apple.com> 2012-08-28 16:59:12 CDT ---
<chrono> was intentionally designed to not be overflow-proof.  However as long
as you keep your durations down to +/- 292 years, you'll be ok, unless try to
represent it with picoseconds.

How about this:

    #include <chrono>
    #include <thread>
    int main() {
        typedef std::chrono::duration<int, std::ratio<24*3600>> days;
        typedef std::chrono::duration<int,
                     std::ratio_multiply<days::period,
                                         std::ratio<3652425, 10000>>> years;
        std::this_thread::sleep_for(years(100));
    }

100 years is an awfully long time to sleep.  And when the computer mistakenly
wakes 100 years from now, you'll have the satisfaction that your great grand
children will have to take care of it.  If that's not quite long enough, double
it.

If you would like to overflow-proof <chrono>, that can be done by creating an
integral (or floating point) emulator that does whatever you like on overflow
(throw? assert?), and then define duration units using that emulator.  As long
as your emulator detects the overflow when asked to convert to a
std::chromo::nanoseconds::rep (long long), you're good to go.

The 292 year thing comes from:

  typedef duration<signed integer type of at least 64 bits, nano> nanoseconds;

2^63 seconds is 292.277 years.  It would hurt to clarify that information in a
note.

-- 
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.



More information about the llvm-bugs mailing list