mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Shawn O. Pearce" <>
To: Junio C Hamano <>
Cc: Robin Rosenberg <>,
Subject: Re: [JGIT PATCH 2/2] Decrease the fetch pack client buffer to the lower minimum
Date: Mon, 11 May 2009 07:10:22 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Junio C Hamano <> wrote:
> "Shawn O. Pearce" <> 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.


  reply	other threads:[~2009-05-11 14:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-10 22:48 [JGIT PATCH 1/2] Fix deadlock in native git protocol client for upload-pack Shawn O. Pearce
2009-05-10 22:48 ` [JGIT PATCH 2/2] Decrease the fetch pack client buffer to the lower minimum Shawn O. Pearce
2009-05-11  0:43   ` Junio C Hamano
2009-05-11  0:55     ` Shawn O. Pearce
2009-05-11  3:51       ` Junio C Hamano
2009-05-11 14:10         ` Shawn O. Pearce [this message]
2009-05-11 14:23           ` (unknown), Carl Mercier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).