homepage

Le vendredi 03 juin 2011 10:02:12, vous avez écrit :
> The implicit timeout in regrtest.py makes it harder to write automated
> test scripts for 3rd party modules. First, you have to remember to
> set --timeout=0 for long running tests.
Ah? Which test is too long for the default timeout? On which kind of computer? 
It's difficult to choose a timeout working on any kind of computer. We use one 
hour because buildbots are configured with a timeout of something like 70 
minutes (just a little bit longer than the regrtest timeout).
> Then, you have to remember not to use the --timeout option when
> compiling --without-threads.
We can change regrtest to just print a warning, and not exit, if Python has no 
thread support and --timeout option is used.
... or we can can improve faulthandler to use SIGALARM+alarm() to implement 
faulthandler.dump_tracebacks_later(), which is already done in the 3rd party 
version of the module. Problem with SIGALRM: it interrupts the current system 
call which fails with EINTR (except for some system calls able to "restart"). 
This problem doesn't matter for regrtest because regrtest uses timeout=True 
and so we exit immediatly on SIGALRM. Another bigger problems: some Python 
tests uses SIGALRM with alarm(), and alarm() is global to the process.
Well, the first solution (display a warning in regrtest, but don't exit) looks 
simpler :-)
> I'd much prefer that there's no timeout unless explicitly specified.
> For the buildbots, I think this could be done in the Makefile.
I set a default timeout for buildbots, because I don't know how to change how 
regrtest is started on all buildbots, but you are right: it can be done in 
"make buildbottests".