Set-up timeouts on thread-related unittests

[Iain Buclaw via Digitalmars-d]

On 20 June 2014 19:08, Sean Kelly via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Friday, 20 June 2014 at 07:13:24 UTC, Iain Buclaw wrote:
>>
>> Hi,
>>
>> I've been seeing a problem on the Debian X32 build system where unittest
>> process just hangs, and require manual intervention by the poor maintainer
>> to kill the process manually before the build fails due to inactivity.
>>
>> Haven't yet managed to reduce the problem (it only happens on a native X32
>> system, but not when running X32 under native x86_64), but thought it would
>> be a good idea to suggest that any thread related tests should be safely
>> handled by self terminating after a period of waiting.
>>
>> Thoughts from the phobos maintainers?
>
>
> I'm surprised that there are thread-related tests that deadlock.
> All the ones I wrote time out for exactly this reason.  Of
> course, getting the timings right can be a pain, so there's no
> perfect solution.


>From my experience deadlocks in the unittest program have been because
of either problems with core.thread or std.parallelism tests.  I am
yet to narrow it down though, so it's just a stab in the dark as to
what the problem may be.