Johannes Sixt <j6t@xxxxxxxx> writes:
> 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.
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
