Fix potential local deadlock during fetch-pack
authorJunio C Hamano <gitster@pobox.com>
Tue, 29 Mar 2011 17:06:19 +0000 (10:06 -0700)
committerJunio C Hamano <gitster@pobox.com>
Tue, 29 Mar 2011 19:20:22 +0000 (12:20 -0700)
commit44d8dc54e73e8010c4bdf57a422fc8d5ce709029
tree98cb72c7df0efc0d35538b26422053d13078ee1b
parent066bf4c2e43c7fb40405843e49f809431314865d
Fix potential local deadlock during fetch-pack

The fetch-pack/upload-pack protocol relies on the underlying transport
(local pipe or TCP socket) to have enough slack to allow one window worth
of data in flight without blocking the writer.  Traditionally we always
relied on being able to have two windows of 32 "have"s in flight (roughly
3k bytes) to stream.

The recent "progressive-stride" change allows "fetch-pack" to send up to
1024 "have"s without reading any response from "upload-pack".  The
outgoing pipe of "upload-pack" can be clogged with many ACK and NAK that
are unread, while "fetch-pack" is still stuffing its outgoing pipe with
more "have"s, leading to a deadlock.

Revert the change unless we are in stateless rpc (aka smart-http) mode, as
using a large window full of "have"s is still a good way to help reduce
the number of back-and-forth, and there is no buffering issue there (it is
strictly "ping-pong" without an overlap).

Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/fetch-pack.c