Set-up timeouts on thread-related unittests

[Iain Buclaw via Digitalmars-d]

On 20 Jun 2014 16:00, "Steven Schveighoffer via Digitalmars-d" <
digitalmars-d at puremagic.com> wrote:
>
> On Fri, 20 Jun 2014 03:13:23 -0400, Iain Buclaw <ibuclaw at gdcproject.org>
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?
>
>
> This could probably be implemented quite simply in druntime.
>
> 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...
>

I don't see a problem using it as default for these.

1) I assume there is already a timeout for the TCP tests.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140620/70b0be64/attachment.html>