From: Johannes Sixt <j.sixt@viscovery.net>
To: James Cloos <cloos@jhcloos.com>
Cc: Junio C Hamano <gitster@pobox.com>, Nicolas Pitre <nico@cam.org>,
git@vger.kernel.org
Subject: Re: [PATCH 1/1] Improve progress display in kB range.
Date: Thu, 23 Apr 2009 08:23:06 +0200 [thread overview]
Message-ID: <49F0094A.6020609@viscovery.net> (raw)
In-Reply-To: <m3ab68mi3q.fsf@lugabout.jhcloos.org>
James Cloos schrieb:
>>>>>> "Junio" == Junio C Hamano <gitster@pobox.com> writes:
>
> Junio> If input_buffer[ret] _were_ the last octet read, [the] loop would
> Junio> be discarding that octet when [it] call[s] more than one xread()
> Junio> to fill the buffer.
>
> That did sem more likely, but I thought I'd throw out the possibility.
>
> I just tried instrumenting fill().
>
> In the first call to fill() during a fetch, xread() returns 4096. In
> the second call to fill(), xread() returns 4095. In all subsequent
> calls to fill(), xread() returns 4096 again.
>
> So, after the second call to xread(), consumed_bytes & 0xFFF == 0xFFF.
>
> It always follows the pattern:
>
> xread() read 0x1000 from fd 0 at 0x80a0900
> ret = 0x1000
> consumed_bytes = 0
> input_len = 0x1000
>
> xread() read 0xFFF from fd 0 at 0x80a0900
> ret = 0xFFF
> consumed_bytes = 0x1000
> input_len = 0xFFF
>
> xread() read 0x1000 from fd 0 at 0x80a0900
> ret = 0x1000
> consumed_bytes = 0x1FFF
> input_len = 0x1000
>
> with all subsequent calls reading 0x1000 and adding 0x1000 to
> consumed_bytes, until the final chuck of tha pack is read.
>
> Also, all calls to xread() where the status lines are being sent from
> the remote server also return 0x1000 octets. Only the second chunck of
> a pack ever returns 0xFFF.
>
> I've tested against a number of remote servers and the pattern holds for
> a wide range of remote server versions.
>
> The pattern also holds for clones over ssh.
>
> Does anyone have an idea of why the second call to read(2), when
> receiving a pack from a remote, always leaves the last octet of the
> buffer free, whereas all other read(2)s fill it?
You could instrument upload-pack.c. There is an xread() around l.237; does
it aways return 4096? And send_client_data() at around l.254; when does it
send 4096 and when 4095 bytes? Read the comment in this if-branch.
upload-pack is run on the server-side; therefore, you can test this only
on local repositories (unless you can replace upload-pack on the server, too).
-- Hannes
next prev parent reply other threads:[~2009-04-23 6:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-19 4:38 [PATCH 0/1] Improve progress display in kB range James Cloos
2009-04-19 4:32 ` [PATCH 1/1] " James Cloos
2009-04-21 4:56 ` Nicolas Pitre
2009-04-21 17:11 ` James Cloos
2009-04-21 17:28 ` Nicolas Pitre
2009-04-21 20:16 ` James Cloos
2009-04-22 14:33 ` James Cloos
2009-04-22 19:44 ` Junio C Hamano
2009-04-22 22:35 ` James Cloos
2009-04-23 6:23 ` Johannes Sixt [this message]
2009-04-24 20:15 ` James Cloos
2009-04-24 21:46 ` Nicolas Pitre
2009-04-24 22:20 ` James Cloos
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49F0094A.6020609@viscovery.net \
--to=j.sixt@viscovery.net \
--cc=cloos@jhcloos.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=nico@cam.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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.
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 NNTP newsgroup(s).