Re: [PATCH 12/12] receive-pack: send keepalives during quiet periods

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

 



On Sat, Jul 16, 2016 at 12:56 AM, Jeff King <peff@xxxxxxxx> wrote:
>> > +               if (use_keepalive == KEEPALIVE_AFTER_NUL && !keepalive_active) {
>> > +                       const char *p = memchr(data, '\0', sz);
>> > +                       if (p) {
>> > +                               /*
>> > +                                * The NUL tells us to start sending keepalives. Make
>> > +                                * sure we send any other data we read along
>> > +                                * with it.
>> > +                                */
>> > +                               keepalive_active = 1;
>> > +                               send_sideband(1, 2, data, p - data, use_sideband);
>> > +                               send_sideband(1, 2, p + 1, sz - (p - data + 1), use_sideband);
>> > +                               continue;
>>
>> Oh, I see why the turn_on_keepalive_on_NUL doesn't work as well as I thought.
>> I wonder if we can use a better read function, that would stop reading at a NUL,
>> and return early instead?
>
> How would you do that, if not by read()ing a byte at a time (which is
> inefficient)? Otherwise you have to deal with the leftovers (after the
> NUL) in your buffer. It's one of the reasons I went with a single-byte
> signal, because otherwise it gets rather complicated to do robustly.

I do not question the concept of a single NUL byte, but rather the
implementation,
i.e. if we had an xread_until_nul you would not need to have a double
send_sideband
here?

>
> -Peff
--
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]