63784 2011-06-30 23:28:42 -0700 Ensure that NWRT workers can always enforce timeouts on DRT/WebKitTestRunner 2012-05-08 14:35:08 -0700 1 1 1 Unclassified WebKit Tools / Tests 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED P2 Normal --- 1 abarth dpranke dpranke eric oldest_to_newest 431001 0 abarth 2011-06-30 23:28:42 -0700 Now that we don't have wedge detection, we need to make sure that new-run-webkit-tests can always kill DumpRenderTree if DumpRenderTree misbehaves. dpranke says this is the case on non-Mac platforms already, but it might not be the case on Chromium for reasons I don't fully understand. 431392 1 dpranke 2011-07-01 13:17:52 -0700 See https://bugs.webkit.org/show_bug.cgi?id=63767#c32 background on this. I am editing the subject for this ... it's not that the NRWT worker's can't kill DRT; they can, obviously. It's that they can't enforce a timeout generically. They rely on the Port's implementation of run_test() to enforce the timeout. In the Chromium bots case, that implementation relies on DRT enforcing it directly. On the non-Chromium webkit ports, the webkit.py/server_process.py code implements non-blocking I/O and enforces the timeout directly. Note that the apple win port (where non-blocking I/O will be trickier) doesn't work at all, and will need to be made to work with non-blocking I/O (or rely on DRT's internal timeout like Chromium does). I think you have misquoted me in the description; hopefully this clarifies things. Also, removing the [Chromium] from this since it will apply to Apple Win as well; of course, you can put the [Chromium] back and file a separate bug (or leverage the existing 'apple win port doesn't work' bug. The reason I put this here is because the non-blocking i/o code is complicated enough that it probably makes sense to be shared across all the ports by revising the server_process code or providing some other common implementation of "spawn this process, write this line to stdin, and read lines from stdout and stderr without blocking for longer than X". 618815 2 dpranke 2012-05-08 14:35:08 -0700 this was fixed with r115903 (and preceding changes). Note that Chromium SL is still using the old mode, but that's a separate issue.