Am 12.02.19 um 18:24 schrieb Junio C Hamano:
>>> 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
