Re: [boost] Boost 1.65.0 Release Candidate 3

Subject: Re: [boost] Boost 1.65.0 Release Candidate 3
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-08-16 11:43:51

Le 16/08/2017 à 01:13, Peppard via Boost a écrit :
> On 2017-08-15 19:45, David Olsen via Boost wrote:
>> 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.)
> Looks like this fixes the bug, but as you said, only in develop. And
> even with the fix,
Thanks for checking.
> I get the impression that the library is in a
> experimental/unstable state with all the time/clock changes over the
> past months. There is even commented out code in some places. And we
> have timespec_now() vs timespec_now_realtime(), the first one being used
> only when BOOST_THREAD_USEFIXES_TIMESPEC is not defined, but if it's not
> defined, the code of timespec_now and timespec_now_realtime is the same,
> right? Do I miss something?
You are right that I have had a lot of trouble lastly with timeout 
issues. Iwill see what can I do this evening.
>
> Anyway, as it stands, it looks like rc3 thread lib does not pass its own
> test suite (stuck e.g. in ex_tennis). Isn't passing the regression test
> suite (at least for major platforms) a requirement for an official release?
Vicente