[Webkit-unassigned] [Bug 36377] Layout test framework doesn't detect wedged tests.

[bugzilla-daemon at webkit.org]

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





--- Comment #5 from Michael Moss <mmoss at chromium.org>  2010-03-19 14:43:53 PST ---
(In reply to comment #3)
> (From update of attachment 51170 [details])
> I'm not wild about this patch, simply because it checks for a wedged thread at
> (potentially) the wrong layer.
> 
> If you compare the chromium and mac implementations of driver.run_test, you'll
> see that the mac version actually implements non-blocking reads from
> DumpRenderTree, so that (in theory) it shouldn't ever wedge up. If we're seeing
> test_shell wedge up, I would probably be happier to change the Chromium
> implementation to do the same thing. We could probably refactor the
> non-blocking code into common logic shared in port/base.py.

Does O_NONBLOCK work on Windows? chromium.py is used on mac/linux/win.

> In particular, this patch won't fix a wedged run if you run with
> --num-test-shells=1 (which runs the whole thing in a single thread).

Yeah, I missed that usage.

> On the other hand, we could decide that it's safer and more generic to do this
> at the thread-management layer (that way we can handle a wedged python thread
> regardless of what it's doing). But I would prefer to be clear about this
> rather than potentially be working around the same underlying problem two
> different ways.

If O_NONBLOCK doesn't work, then this would still have the issue with
--num-test-shells=1, right? Or is that not a big deal since --num-test-shells=1
is more of a debugging mode, and at least the buildbots would be able to
recover better?

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