Theo and I preferred this approach as it allows each test to determine what a reasonable timeout should be, using dynamic information if desired. Also, we understood that getting signal-safety right in the Python framework was hard, so we figured this was less likely to break. That said, we'd be happy to have these merged without timeout support if that's what it takes. :-) Thanks for reviewing these! Jamey <div class="gmail_quote">On May 8, 2014 10:49 AM, "Eric Anholt" <<a href="mailto:eric@anholt.net">eric@anholt.net</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Jamey Sharp <<a href="mailto:jamey@minilop.net">jamey@minilop.net</a>> writes: > From: TheoH <<a href="mailto:Theo0x48@gmail.com">Theo0x48@gmail.com</a>> > > We've observed hangs on some drivers in these calls, which make it > harder to run the rest of the Piglit test suite. I know people have been working on having timeout support in the framework, which seems much better than having it ad-hoc in tests that we've discovered already hang on some systems. Any framework folks have status on that? </blockquote></div>