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@lists.boost.org>:
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
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