<p dir="ltr"><br>
On 20 Jun 2014 16:00, "Steven Schveighoffer via Digitalmars-d" <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br>
><br>
> On Fri, 20 Jun 2014 03:13:23 -0400, Iain Buclaw <<a href="mailto:ibuclaw@gdcproject.org">ibuclaw@gdcproject.org</a>> wrote:<br>
><br>
>> Hi,<br>
>><br>
>> 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.<br>

>><br>
>> 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.<br>

>><br>
>> Thoughts from the phobos maintainers?<br>
><br>
><br>
> This could probably be implemented quite simply in druntime.<br>
><br>
> I'd be hesitant to make it default, but it would be nice to tag unit tests as having a maximum timeout. Yet another case for using attributes on unit tests and RTInfo for modules...<br>
></p>
<p dir="ltr">I don't see a problem using it as default for these.</p>
<p dir="ltr">1) I assume there is already a timeout for the TCP tests.</p>
<p dir="ltr">2) If the test runs a shortlived (ie: increments some global value) function in 100 parallel threads, the maintainer of the module who wrote that test should safely be able to assume that it shouldn't take more than 60 seconds to execute.</p>