git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [JGIT PATCH 2/2] Decrease the fetch pack client buffer to the lower minimum

From
Shawn O. Pearce <spearce@spearce.org>
Date
May 11, 2009, 14:10 UTC
Message-ID
<20090511141021.GJ30527@spearce.org>
In-Reply-To
<7vr5yws3fe.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
Show 11 quoted lines
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
> > In step 3 during the first round the client can send up to 2 blocks
> > worth of data, with 32 haves per block.  This means the client
> > writes 2952 bytes of data before it reads.
> 
> Sorry, perhaps I am being extremely slow, but even if the client writes
> millions of bytes before it starts reading, I do not see how it would be a
> problem as long as the other side reads these millions of bytes before
> saying "Ok, I've heard about them and my response so far is Ack-continue
> (or NAK)", which the client needs to read.

Ok, maybe my understanding of the fetch-pack/upload-pack protocol is incorrect.

If multi_ack is enabled then isn't it possible for the remote to return "ACK %s continue" for the first 63 "have %s" lines the client sent?

E.g. the case is the client has only one ref, and has only 1 commit the other side doesn't have, and the other side has only one ref, and has only 1 commit the client doesn't have (so the client will fetch 1 commit). In such a case, the client will blast 64 have lines before pausing to listen to the server. But the server will have 63 of those lines, and will try to send "ACK %s continue" in vain at the client, hoping it will stop enumerating along that branch.

If there is insufficient buffering along one of those writers, the entire thing deadlocks.

-- 
Shawn.
Previous: Junio C HamanoNext: Carl Mercier
Message 6 of 7 in “Fix deadlock in native git protocol client for upload-pack”
  1. 1/2 Fix deadlock in native git protocol client for upload-packShawn O. Pearce, May 10, 2009
  2. 2/2 Decrease the fetch pack client buffer to the lower minimumShawn O. Pearce, May 10, 2009
  3. Junio C HamanoMay 11, 2009
  4. Shawn O. PearceMay 11, 2009
  5. Junio C HamanoMay 11, 2009
  6. Shawn O. PearceMay 11, 2009
  7. (unknown)Carl Mercier, May 11, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.