From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Xu Subject: Re: [kvm-unit-tests PATCH 2/2] run_tests: allow run tests in parallel Date: Thu, 5 Jan 2017 10:35:39 +0800 Message-ID: <20170105023539.GM22664@pxdev.xzpeter.org> References: <1483266886-25050-1-git-send-email-peterx@redhat.com> <1483266886-25050-3-git-send-email-peterx@redhat.com> <20170102201824.GA2892@potion> <20170103024501.GA22664@pxdev.xzpeter.org> <20170104145541.GI2395@potion> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, Paolo Bonzini , Andrew Jones To: Radim =?utf-8?B?S3LEjW3DocWZ?= Return-path: Received: from mx1.redhat.com ([209.132.183.28]:36748 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030355AbdAECfo (ORCPT ); Wed, 4 Jan 2017 21:35:44 -0500 Content-Disposition: inline In-Reply-To: <20170104145541.GI2395@potion> Sender: kvm-owner@vger.kernel.org List-ID: 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