[Piglit] [PATCH] framework: avoid blocking joins, allowing ^C to work
Ilia Mirkin
imirkin at alum.mit.edu
Tue Feb 18 07:58:46 PST 2014
On Tue, Feb 18, 2014 at 10:46 AM, Tom Stellard <tom at stellard.net> wrote:
> On Sat, Feb 15, 2014 at 01:30:20PM -0500, Ilia Mirkin wrote:
>> On Sat, Feb 15, 2014 at 7:37 AM, Dylan Baker <baker.dylan.c at gmail.com> wrote:
>> > On Saturday, February 15, 2014 03:27:44 AM Ilia Mirkin wrote:
>> >> Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
>> >> ---
>> >> framework/core.py | 20 ++++++++++++++------
>> >> 1 file changed, 14 insertions(+), 6 deletions(-)
>> >>
>> >> diff --git a/framework/core.py b/framework/core.py
>> >> index 4bcaa82..7b2083b 100644
>> >> --- a/framework/core.py
>> >> +++ b/framework/core.py
>> >> @@ -31,6 +31,7 @@ import sys
>> >> import time
>> >> import traceback
>> >> from cStringIO import StringIO
>> >> +import itertools
>> >> import multiprocessing
>> >> import multiprocessing.dummy
>> >> import importlib
>> >> @@ -578,22 +579,29 @@ class TestProfile(object):
>> >> chunksize = 1
>> >>
>> >> if env.concurrent == "all":
>> >> - multi.imap(test, self.test_list.iteritems(), chunksize)
>> >> + testiter = multi.imap(test, self.test_list.iteritems(),
>> >> chunksize) elif env.concurrent == "none":
>> >> - single.imap(test, self.test_list.iteritems(), chunksize)
>> >> + testiter = single.imap(test, self.test_list.iteritems(),
>> >> chunksize) else:
>> >> # Filter and return only thread safe tests to the threaded pool
>> >> - multi.imap(test, (x for x in self.test_list.iteritems() if -
>> >> x[1].runConcurrent), chunksize)
>> >> + iter1 = multi.imap(test, (x for x in self.test_list.iteritems()
>> >> + if x[1].runConcurrent), chunksize) #
>> >> Filter and return the non thread safe tests to the single pool -
>> >> single.imap(test, (x for x in self.test_list.iteritems() if not -
>> >> x[1].runConcurrent), chunksize)
>> >> + iter2 = single.imap(test, (x for x in
>> >> self.test_list.iteritems() + if not
>> >> x[1].runConcurrent), chunksize) + testiter =
>> >> itertools.chain(iter1, iter2)
>> >>
>> >> # Close and join the pools
>> >> # If we don't close and the join the pools the script will exit
>> >> before # the pools finish running
>> >> multi.close()
>> >> single.close()
>> >> +
>> >> + # This waits for all the results to arrive in a non-blocking
>> >> + # fashion. This in turn allows ^C to work to stop a piglit run.
>> >> + for test in testiter:
>> >> + pass
>> >> +
>> >> multi.join()
>> >> single.join()
>> >
>> > The code is valid and works as advertised. I actually like what's happening
>> > now since ctrl-c kills the currently running test, and can be used to kill
>> > stuck tests, but if other like the previous behavior better, it isn't a big
>> > deal to me either way.
>> >
>> > Reviewed-by: Dylan Baker <baker.dylan.c at gmail.com>
>>
>> Hmmmm... I hadn't thought about that. It's just really hard to kill
>> piglit right now -- you have to ^Z + kill -9 %%. How does using ^C in
>> a parallel run (which I understand is the majority use-case) possible
>> to kill the 'current' test -- there is no current test.
>>
>> Anyone else with opinions on what ^C should do while running piglit?
>>
>
> I would prefer ^C kill whatever tests are currently running. This way
> you can still get usable results if one of the tests hangs. Also, since
> Ctrl+\ can be used to stop all the tests, I doesn't seem like there is much
> value in having ^C duplicate this behavior.
Well, it's just the expected behaviour -- for any program running on a
UNIX-y system, ^C terminates the program (from a shell). Of course you
can do stuff like while true; do program; done, and then ^C is less
effective, but that's the exception (and an annoying one at that). But
I won't push this point since it seems like you all are used to and
like the current way.
-ilia
More information about the Piglit
mailing list