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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Dec 9, 2014 at 2:41 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Jeff King <peff@xxxxxxxx> writes:
>
>> 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?
>
>> 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.
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

I'm getting failures on my mac too, I assume filesystem-related.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]