Re: [Qemu-devel] [kvm-unit-tests PATCH 2/2] run_tests: allow run tests in parallel

[Peter Xu]

On Wed, Jan 04, 2017 at 03:55:42PM +0100, Radim Krčmář wrote:

[...]

> >>   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.

Agree. After a second thought, I think it's okay we use "jobs" here as
long as we make sure we don't spawn background tasks other than these
test cases.

> 
> > 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?)

My understanding:

SIGCHLD is used by internal bash. For every command we write (like a
"ls" in the script), we should have forked another process to load the
"/bin/ls" binary, and when this command (in this case "ls") finishes,
it'll send one SIGCHLD to the main process. This should happen for
each non-builtin bash commands, and bash program is managing these
SIGCHLDs internally by default. So, we should not be able to trap
SIGCHLD in bash.

There is one way to trap it, only if we provide:

  set -m

to turn off the job controls of bash. However if with that, we'll
trigger the SIGCHLD handler for *every* task we run, even for the
normal commands like "ls". I suppose that's not what we want (we want
to only trap those background $QEMU processes). That's why I used
SIGUSR1 instead of SIGCHLD.

Of course, after I know "wait -n", it becomes clumsy. :-)

-- peterx