[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [kvm-unit-tests PATCH 2/2] run_tests: allow run tests i
From: |
Radim Krčmář |
Subject: |
Re: [Qemu-devel] [kvm-unit-tests PATCH 2/2] run_tests: allow run tests in parallel |
Date: |
Wed, 4 Jan 2017 15:55:42 +0100 |
2017-01-03 10:45+0800, Peter Xu:
> On Mon, Jan 02, 2017 at 09:18:24PM +0100, Radim Krčmář wrote:
>> 2017-01-01 18:34+0800, Peter Xu:
>> > diff --git a/scripts/functions.bash b/scripts/functions.bash
>> Couldn't the queue be much simpler ...
>>
>> > + else
>> > + RUNTIME_log_file=$ut_default_log_file
>> > + "$@"
>> > + fi
>> > }
>> >
>> > function for_each_unittest()
>> > @@ -51,5 +62,10 @@ function for_each_unittest()
>> > fi
>> > done
>>
>> ... like this:
>>
>> while [ "`jobs | wc -l`" -gt $ut_run_queues ]; do
(Uh, should be -ge, and `wc -l` always has reasonable output, so quotes
are not necessary. Quotes would make more sense around the variable.)
>> wait
>
> I suppose you mean "wait -n" here?
Yes, sorry.
> And also a "if" should suffice
> here, though a "while" won't hurt as well.
I agree.
(I was lazy to read the manual to confirm, hence the first mistake as
well. I just remembered that bash wait has this weird behavior and
assumed that the wait in task_enqueue is already doing that ...)
>> done
>> run_task "$cmd" "$testname" "$groups" "$smp" "$kernel" "$opts" "$arch"
>> "$check" "$accel" "$timeout" &
>
> I think this might work, however it has assumption that these $cmd
> tasks are the only jobs that is running in the background.
Yes, but run_task is already in a sub shell, so its jobs don't matter
and we can easily guarantee that for_each_unit_test won't spawn more.
> I didn't notice the "-n" parameter for "wait", otherwise I won't
> bother using SIGUSR1 at all. :)
(Btw. why couldn't you use SIGCHLD?)
Re: [Qemu-devel] [kvm-unit-tests PATCH 0/2] run_tests: support concurrent test execution, Paolo Bonzini, 2017/01/02