Re: [boost] Boost 1.65.0 Release Candidate 3

Subject: Re: [boost] Boost 1.65.0 Release Candidate 3
From: Nana Sakisaka (n.sakisaka_at_[hidden])
Date: 2017-08-16 23:54:51

A month ago, I have reported a release-tools' issue regarding malformed
json for release files:

https://github.com/boostorg/release-tools/issues/3

It did get attention by Rene (I think), but it has not been fixed yet.
If we are going for RC4, could you merge this too?
The fix is trivial (just deleting 1 character), so it won't be that hard.

I'm having problems with automated checksum validation for my CI server,
because I can't feed this file to a formal JSON parser.

Nana

2017-08-16 20:43 GMT+09:00 Vicente J. Botet Escriba via Boost <
boost_at_[hidden]>:

> 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/d4cff01c724f1355fe
>>>> f0990f3d6d678e52f61fd0
>>>>
>>>>
>>>> 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
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman
> /listinfo.cgi/boost
>