testsuite and hardcoded timeouts

[Quentin Barnes]

>>You might luck out with the caching helping the later attempts skip 
>>some of the phases of the translator and avoid those times on the 
>>later runs. However, restarting 4 or 5 times is probably not going to 
>>help that much if the time required to generate the module is way 
>>larger than the time out.
>
>I was not thinking that the expiration of the time out would restart 
>generating the module.   Just warn the user that the test is taking 
>longer than expected.   So the purpose of the timer is just to print  
>"hay I am taking too long".  The real timeout that would cause the test 
>to fail happens after 4 or 5 warning messages have been printed.  This 
>way the user is given a heads up that something may be wrong before 
>waiting for a timeout that is long enough for even the slowest system to 
>normally complete the test.

Ah, maybe there is some middle ground here.  Instead of putting the
effort into figuring out some portable method for dynamic timeouts,
just change the behavior for a timeout to be user-settable --
default behavior is fatal like it is now, or as an alternative, just
output an advisory warning and do an "exp_continue".

Would this be a reasonable change for now?

If so, I could code up this work as part of my ARM Systemtap port
and post it to the list.

>>The timeout is there to make sure that forward progress is made on the 
>>testing. We would prefer to have the test fail in a reasonable amount 
>>of time than to have a test hang for an unreasonable amount of time 
>>and not get any results at all. The translator internals are pretty 
>>much a black box to the testing harness, so the timer is used to judge 
>>when the the test isn't making forward progress. Too bad there 
>>couldn't be an equivalent to a watchdog for the testing harness, e.g. 
>>if the test is making forward progress, leave the test be.
>>
>>-Will
>
>-- 
>David Wilder
>IBM Linux Technology Center
>Beaverton, Oregon, USA 
>dwilder@us.ibm.com
>(503)578-3789

Quentin