Re: [RFC PATCH 3/3] test-lib: add the '--stress' option to run a test repeatedly under load

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 6, 2018, 00:22 UTC
Message-ID: <xmqqefavbj28.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20181205213625.GD19936@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 13 quoted lines

> But the ^C case is interesting. Try running your script under "sh -x"
> and hitting ^C. The signal interrupts the first wait. In my script (or
> yours modified to use a single wait), we then proceed immediately to the
> "exit", and get output from the subshells after we've exited.
>
> But in your script with the loop, the first wait is interrupted, and
> then the _second_ wait (in the second loop iteration) picks up all of
> the exiting processes. The subsequent waits are all noops that return
> immediately, because there are no processes left.
>
> So the right number of waits is either "1" or "2". Looping means we do
> too many (which is mostly a harmless noop) or too few (in the off chance
> that you have only a single job ;) ). So it works out in practice.

Well, if you time your ^C perfectly, no number of waits is right, I am afraid. You spawn N processes and while looping N times waiting for them, you can ^C out of wait before these N processes all die, no?

> But I think a more clear way to do it is to simply wait in the signal
> trap, to cover the case when our original wait was aborted.

Sounds good.