Boost logo

Boost :

Subject: Re: [boost] [thread]Forever sleeping
From: Niklas Angare (li51ckf02_at_[hidden])
Date: 2017-02-28 09:21:56


"Vicente J. Botet Escriba wrote:
> Le 24/02/2017 à 15:23, Vicente J. Botet Escriba via Boost a écrit :
>> 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/544eda51bdf0c62b2f29dea6fe1cf935ad62580e
>>>>
>>> I'll rollback it and analyze more deeply the change.
>>>
>> Done.
>>
>> https://github.com/boostorg/thread/commit/9bbf9bed80836282263ec0bdea0adf5c1fa3621b
>> Please, let me know if it works again.
> After this commit the regression tests continued to be available.
> I'm really sorry if my bug was the cause of then been not refreshed.
> If it was the case, our test system would need some improvements.

The fact that it ruins the entire run might be specific to my setup. But
other runners that are running tests remotely due to cross-compilation may
also have trouble killing hung test processes.

Does the Boost.Thread tests or Boost.Test in general block any signals,
thereby making it harder to stop the processes? I'm running the tests over
ssh but I'm not sure which signals would be sent to the other side when the
client is stopped by Boost.Build. Maybe SIGHUP?

Regards,

Niklas Angare
 


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk