From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 103074 invoked by alias); 27 Mar 2015 00:04:37 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 103029 invoked by uid 48); 27 Mar 2015 00:04:34 -0000 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/60421] std::this_thread::sleep_for doesn't sleep for all arguments Date: Fri, 27 Mar 2015 03:47:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 4.8.2 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: REOPENED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 6.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: target_milestone Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-03/txt/msg03076.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60421 Jonathan Wakely changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|5.0 |6.0 --- Comment #7 from Jonathan Wakely --- You're right, sorry, I ended up reducing the scope of the fix and it only deals with PR58038, see https://gcc.gnu.org/ml/libstdc++/2015-03/msg00078.html for some commentary. At one point I added: if (__s < chrono::seconds::zero() || __s < __rtime) __s = chrono::seconds::max(); which would detect some cases where the duration_cast to chrono::seconds overflows, but that overflow is still undefined behaviour so I didn't include that in the commit. I want to fix it properly to avoid any undefined behaviour (probably converting to duration and comparing to duration::max()). > I mean when I sleep for UINT64_MAX hours/years/millenia, you can't possibly > wrap that into a single nanosleep call due to the limitations of the type > time_t of the tv_sec parameter of the first argument to nanosleep. One > obviously can not get around using loop. To be honest, I'm not very concerned about the failure to sleep for 290 billion years, if we sleep for duration::max() instead of duration::max() and don't loop you'll never know the difference. > Additionally, the nanosleep code is also missing proper EINTR handling, > which again could break the sleep. Yes, see the mailing list post above. I'll deal with this for gcc 6.