Bug 63784 – Ensure that NWRT workers can always enforce timeouts on DRT/WebKitTestRunner

• Status: RESOLVED
• Resolution: FIXED
• Component: Tools / Tests

[Adam Barth]

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.

[Dirk Pranke]

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

[Dirk Pranke]

this was fixed with r115903 (and preceding changes). Note that Chromium SL is still using the old mode, but that's a separate issue.