[Piglit] ctrl-c behaviour

[Ian Romanick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/11/2011 09:22 AM, Eoff, Ullysses A wrote:
>> -----Original Message-----
>> From: piglit-bounces+ullysses.a.eoff=intel.com at lists.freedesktop.org
>> [mailto:piglit-bounces+ullysses.a.eoff=intel.com at lists.freedesktop.org]
>> On Behalf Of Dave Airlie
>> Sent: Thursday, February 10, 2011 7:07 PM
>> To: piglit
>> Subject: [Piglit] ctrl-c behaviour
>>
>> So it used to be that I'd start a piglit run, and when one tripped
>> over the GPU and it had to reset, I'd hit ctrl-c and it would move
>> onto he next test and my test run would complete and I'd get a decent
>> log, now when I hit Ctrl-C it kills the test run.
> 
> While adding the concurrency support, I discussed this issue with a few
> of my colleagues who have been using piglit for a while.  Some of them
> where fine with the ctrl-c behavior change, others were not (or at least
> thought it was going to be a minor inconvenience).  My apologies
> for not discussing this directly with the rest of the community, first; and
> for not noting it in the patches (perhaps, I overlooked that).
> 
> The issue is that multiple tests are running concurrently and when the
> user hits Ctrl-C, which test(s) do you interrupt.  Well, there are a few
> options to consider (and perhaps more):
> 
> 1. We could kill all tests that are currently running and then
> move on to the next set of tests in the test queue.
> 
> 2. We could interrupt the main program, write the results-so-far, and
> exit the test run. (this is the current behavior)
> 
> 3. We could pause all tests, all logging, then present the user with
> a list of tests currently running. Next, prompt the user which test to 
> interrupt.  Then, interrupt the chosen test and resume the test queue
> and logging.

4. Kill the test that has been running the longest.

The usual case is that a test hangs.  There are a couple of the GLX
tests that are notorious for this.  Often you'll want to kill that test
and move on.  Since most tests have a very short run time, killing the
one that has been around the longest will cover the 90% case.

> Options 1 and 3 where not chosen because of a few technical reasons:
> 
> * Python does not have direct support for propagating signals to
> threads (at least not in a cross-platform way).
> 
> * Python does not have support for interrupting or killing
> a subprocess directly; Although, "terminate" and "kill" were introduced
> in the subprocess.Popen class in Python 2.6.  However, Piglit claims
> to be compatible with Python 2.4 or greater.  I could see dropping 2.4
> support, but not 2.5.2 or later.
> 
> Option 2 was the easiest choice since there is better Python support
> for achieving such behavior.
> 
>> Any way we can the old behaviour back or at least an option for it?
> 
> We could add an option to disable concurrent test runs, thus disabling
> thread usage all together.  Without the threads, ctrl-c should work as
> it previously did.  If we added an option, would it be to turn-on
> threading or turn-off threading (this depends on what we'd like
> the default behavior to be; threaded or not threaded)?

It could be dynamic.  I suspect that Dave and some other people only run
tests that use the GPU.  I doubt he runs all the GLSL parser tests while
he's working on sRGB functionality.  How hard would it be to detect that
all of the selected tests are in the "uses the GPU" group and
automatically disable threading in that case?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1VjC8ACgkQX1gOwKyEAw/iEQCff1Jl1j7rRhQvAX1fZl96VAen
zY4AoI2+QsIoPAgHW0bQ4WqSrRwdu6th
=Edya
-----END PGP SIGNATURE-----