Le 28/02/2017 à 10:20, Niklas Angare via Boost a écrit :
"Vicente J. Botet Escriba wrote:
Le 24/02/2017 à 13:46, Vicente J. Botet Escriba a écrit :
Le 22/02/2017 à 23:39, Niklas Angare via Boost a écrit :
Recent runs of my regression test runner NA-QNX660-x86 leave a lot of Boost.Thread test executables stuck in nanosleep, waiting for a condition variable, or both. ... https://github.com/boostorg/thread/commit/544eda51bdf0c62b2f29dea6fe1cf935ad...
I'll rollback it and analyze more deeply the change.
Done.
https://github.com/boostorg/thread/commit/9bbf9bed80836282263ec0bdea0adf5c1f...
Please, let me know if it works again.
The latest run failed with similar symptoms. I noticed you made another change so I decided to run the Boost.Thread tests manually.
Commit c7348b29 left seven stuck test processes and b2 reported "failed updating 85 targets". Commit 9bbf9bed did not leave any stuck test processes and b2 reported "failed updating 16 targets".
The following test processes got stuck: test_2741 test_2741_lib ex_tennis ex_tennis_lib ex_xtime ex_xtime_lib test_thread_lib
It looks like these test are failing for other test runners as well but I don't know if it's for the same reason.
I may not be able to help or tend to the runners for the next two weeks. I'm taking a look just now.
I've an hint. https://github.com/boostorg/thread/commit/c7348b29cf8bfa1272645d04784419d37e... Must be more restrictive. // old behavior was fine for monotonic - return do_wait_until(lock, boost::detail::timespec_plus(timeout, boost::detail::timespec_now())); + return do_wait_until(lock, boost::detail::timespec_plus(timeout, boost::detail::timespec_now_realtime())); -#ifdef CLOCK_MONOTONIC +#if defined CLOCK_MONOTONIC && defined BOOST_THREAD_USEFIXES_TIMESPEC if ( ::clock_gettime( CLOCK_MONOTONIC, &ts ) ) I'll commit these changes soon. Vicente