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

Re: [RFC/PATCH] pkt-line: allow writing of LARGE_PACKET_MAX buffers

From
Junio C Hamano <gitster@pobox.com>
Date
Dec 9, 2014, 22:41 UTC
Message-ID
<xmqqa92wla34.fsf@gitster.dls.corp.google.com>
In-Reply-To
<20141209180916.GA26873@peff.net>
Jeff King <peff@peff.net> writes:
Show 11 quoted lines
> On Tue, Dec 09, 2014 at 12:49:58PM -0500, Jeff King wrote:
>
>> Another option would be to use a static strbuf. Then we're only wasting
>> heap, and even then only as much as we need (we'd still manually cap it
>> at LARGE_PACKET_MAX since that's what the protocol dictates). This would
>> also make packet_buf_write more efficient (right now it formats into a
>> static buffer, and then copies the result into a strbuf; probably not
>> measurably important, but silly nonetheless).
>
> Below is what that would look like. It's obviously a much more invasive
> change, but I think the result is nice.

Yes, indeed. Is there any reason why we shouldn't go with this variant, other than "it touches a bit more lines" that I am not seeing?

Show 10 quoted lines
> Let's switch to using a strbuf, with a hard-limit of
> LARGE_PACKET_MAX (which is specified by the protocol).  This
> matches the size of the readers, as of 74543a0 (pkt-line:
> provide a LARGE_PACKET_MAX static buffer, 2013-02-20).
> Versions of git older than that will complain about our
> large packets, but it's really no worse than the current
> behavior. Right now the sender barfs with "impossibly long
> line" trying to send the packet, and afterwards the reader
> will barf with "protocol error: bad line length %d", which
> is arguably better anyway.

Anything older than 1.8.3 is affected by this, but only when the sending side has to send a large packet. It is between failing because the sender cannot send a large packet and failing because the receiver does not expect such a large packet to come, and either way the whole operation will fail anyway, so there is no net loss.

Previous: Jeff KingNext: Michael Blume
Message 3 of 20 in “pkt-line: allow writing of LARGE_PACKET_MAX buffers”
  1. pkt-line: allow writing of LARGE_PACKET_MAX buffersJeff King, Dec 9, 2014
  2. Jeff KingDec 9, 2014
  3. Junio C HamanoDec 9, 2014
  4. Michael BlumeDec 10, 2014
  5. pkt-line: allow writing of LARGE_PACKET_MAX buffersJeff King, Dec 10, 2014
  6. Eric SunshineDec 10, 2014
  7. Eric SunshineDec 10, 2014
  8. Eric SunshineDec 10, 2014
  9. Jeff KingDec 10, 2014
  10. 0/3 convert read_packed_refs to use strbufJeff King, Dec 10, 2014
  11. 1/3 read_packed_refs: use a strbuf for reading linesJeff King, Dec 10, 2014
  12. 2/3 read_packed_refs: pass strbuf to parse_ref_lineJeff King, Dec 10, 2014
  13. 3/3 read_packed_refs: use skip_prefix instead of static arrayJeff King, Dec 10, 2014
  14. Junio C HamanoDec 10, 2014
  15. pkt-line: allow writing of LARGE_PACKET_MAX buffersJeff King, Dec 10, 2014
  16. Eric SunshineDec 10, 2014
  17. Eric SunshineDec 10, 2014
  18. Jeff KingDec 10, 2014
  19. Johannes SixtDec 9, 2014
  20. Jeff KingDec 9, 2014

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.