Set-up timeouts on thread-related unittests

[Steven Schveighoffer via Digitalmars-d]

On Fri, 20 Jun 2014 13:13:30 -0400, Iain Buclaw via Digitalmars-d  
<digitalmars-d at puremagic.com> wrote:

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

No, I mean that druntime would run all unit tests with an expectation that  
each unit test should time out after N seconds.

I think it's much cleaner and less error prone to implement the timeout in  
the unittest runner than in the unit test itself.

But of course, there might be exceptions, we can't put those restrictions  
on all code. A nice feature would be if the default was to have a timeout  
of say 1 second, and then allow users to specify an alternate/infinite  
timeout based on a UDA.

-Steve