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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
