[Webkit-unassigned] [Bug 39203] [DRT/Chromium] Increase the time out value

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=39203





--- Comment #10 from Dirk Pranke <dpranke at chromium.org>  2010-05-20 16:16:32 PST ---
(In reply to comment #9)
> Dirk is way more familiar with the current state of this code than I am.
> 
> (In reply to comment #4)
> > It seems like the DRT timeout should be longer than the script timeout (just like how you mentioned it was 10 seconds vs 6 seconds for test_shell and the script).
> 
> I actually think it's the other way around. If DRT times out, then it can dump whatever results it has so far and then load the next test. If the script times out, all it can do is kill DRT.
> 
> new-run-webkit-tests passes the per-test timeout to test_shell when it's running the test, so that value isn't even used for new-run-webkit-tests.
> 

The script logic actually varies by port. 

The WebKit Mac port of new-run-webkit-tests (and I think the Chromium DRT port) use non-blocking I/O and a timeout to enforce timeouts in the script. This way the script can abort before DRT does, and DRT doesn't have to have a concept of a timeout. 

The Chromium ports (all platforms) pass the timeout to TestShell, and rely on Test Shell to enforce the timeout. At one point there was code in some configurations of new-run-webkit-tests to try and catch timeouts, but not in the regular code path.

We do things this way because there is no way to do a non-blocking read using select on Windows from Python. I think (but am not positive) that you can do this in (cygwin?) Perl on Windows, and so WebKit Win doesn't have this problem.

So, DRT and test_shell are definitely different.

Separately, I am in the middle of trying to change new-run-webkit-tests to detect wedged threads and recover, in order to work around the Python multi-threading issues we're seeing. So it *may* be feasible to change test_shell to match DRT here, but I can't say so conclusively yet.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.