Re: [PATCH] Fix potential local deadlock during fetch-pack

From: Shawn Pearce <spearce@spearce.org>
Date: Mar 29, 2011, 17:30 UTC
Message-ID: <AANLkTi=UDPFkox9Gsgv5Bbfsb-VTRweY9D2SNAAhptAc@mail.gmail.com>
In-Reply-To: <AANLkTikZ=POeQi5nnt8D9v4Z-_OaXNrXDjP2awWUtKzA@mail.gmail.com>

On Tue, Mar 29, 2011 at 10:22, Shawn Pearce <spearce@spearce.org> wrote:

Show 10 quoted lines

> On Tue, Mar 29, 2011 at 10:06, Junio C Hamano <gitster@pobox.com> wrote:
>> 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 a batch of 32 "have"s in flight (roughly 1.5k
>
>> +               count += flush_limit;
>
> Nak. You still deadlock because when count reaches PIPESAFE_FLUSH you
> still double it to 2*PIPESAFE_FLUSH here. Instead I think you mean:

I take this comment back. Re-reading fetch-pack.c the next_flush() method is accepting as input a running counter of how many have lines have already been sent to the remote peer, and is never reset to 0. Therefore it is necessary to add the next round size to count and return it.

-- 
Shawn.