Re: [Patch v1 3/3] t5562: replace /dev/zero with a pipe from generate_zero_bytes

From: Johannes Sixt <j6t@kdbg.org>
Date: Feb 12, 2019, 20:50 UTC
Message-ID: <f3b506bb-52eb-3a1f-ba3d-0cf327271ab2@kdbg.org>
In-Reply-To: <xmqqd0nwex7w.fsf@gitster-ct.c.googlers.com>

Am 12.02.19 um 18:24 schrieb Junio C Hamano:

Show 20 quoted lines

>>> diff --git a/t/t5562-http-backend-content-length.sh b/t/t5562-http-backend-content-length.sh
>>> @@ -143,14 +143,14 @@ test_expect_success GZIP 'push gzipped empty' '
>>>  test_expect_success 'CONTENT_LENGTH overflow ssite_t' '
>>>         NOT_FIT_IN_SSIZE=$(ssize_b100dots) &&
>>> -       env \
>>> +       generate_zero_bytes infinity  | env \
>>>                 CONTENT_TYPE=application/x-git-upload-pack-request \
>>>                 QUERY_STRING=/repo.git/git-upload-pack \
>>>                 PATH_TRANSLATED="$PWD"/.git/git-upload-pack \
>>>                 GIT_HTTP_EXPORT_ALL=TRUE \
>>>                 REQUEST_METHOD=POST \
>>>                 CONTENT_LENGTH="$NOT_FIT_IN_SSIZE" \
>>> -               git http-backend </dev/zero >/dev/null 2>err &&
>>> +               git http-backend >/dev/null 2>err &&
> 
> Doesn't this "inifinity" mode have the same issue that was worked
> around by 6129c930 ("test-lib: limit the output of the yes utility",
> 2016-02-02) on Windows?  If I read correctly, the process upstream
> of the pipe (in this case, perl producing a stream of infinite NULs)
> would not die when the downstream stops reading with SIGPIPE.

I think we do not have to worry, and the reason is that the justification for 6129c930 is simply wrong.

As I did not find the patch series discussed here to pull and test, I repeated the timing tests with t7610-mergetool.sh with and without 6129c930 reverted, and the difference is only in the noise. The reason t7610 takes so long on Windows looks more like a consequence of the 10,000 processes that it spawns. It is a mystery to me how I came to the conclusion that the change in 6129c930 would make a difference. :-(

-- Hannes