$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] Boost 1.65.0 Release Candidate 3
From: David Olsen (dolsen_at_[hidden])
Date: 2017-08-15 17:45:40
On 8/15/2017 6:10 AM, Peppard via Boost wrote:
> 
> However I maybe found another regression introduced after the 1.64
> release, this time in Boost.Thread (with pthread implementation and
> BOOST_HAS_NANOSLEEP). A minimal example:
> 
> #include <boost/thread/thread.hpp>
> 
> int main() {
>          boost::this_thread::sleep(boost::posix_time::seconds(1));
> }
> 
> This sleeps "forever", however a slightly more complicated program might
> not. I bisected it to this commit:
> https://github.com/boostorg/thread/commit/d4cff01c724f1355fef0990f3d6d678e52f61fd0
> 
> The problem seems to be the BOOST_THREAD_USEFIXES_TIMESPEC define, which
> alters some internal behavior, effectively changing
> 
>> nanosleep({0, 999366710}, NULL)
> 
> into
> 
>> nanosleep({1501988898, 350057596}, [stuck for a very long time]
> 
> . If the sleep is called inside a boost::thread, hidden::sleep_until is
> implemented via condition.do_wait_until instead of nanosleep, this
> works. For me a slightly extended test code works as expected if
> compiled in debug mode but is stuck in release mode. I'm testing under
> Linux with GCC 7.1 and a Clang++ 5.0.0 snapshot.
This bug was fixed in the develop branch a couple weeks ago. 
https://github.com/boostorg/thread/pull/127
(At least it looks like the same bug.  I never tracked down the commit 
that introduced the bug, or figured out whether or not it was a regression.)
-- David Olsen NVIDIA - PGI