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

Johannes Sixt [off-list ref] writes:

Am 12.02.19 um 18:24 schrieb Junio C Hamano:

quoted

quoted

quoted

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.

That's kinda surprising but in a pleasant way---it's good that we
have one less thing we need to worry about.

Thanks.

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