Re: [REROLL PATCH 5/8] Support taking over transports

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 9, 2009, 21:08 UTC
Message-ID: <7vein3onxf.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20091209151718.GE15673@Knoppix>

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:

Show 12 quoted lines

>> Who guarantees that reading from the (FILE *)data->out by strbuf_getline()
>> that eventually calls into fgetc() does not cause more data be read in the
>> buffer assiciated with the (FILE *) than we will consume?  The other FILE*
>> you will make out of helper->out won't be able to read what data->out has
>> already slurped in to its stdio buffer.
>
> Causality impiles this can happen only if buffered version gets its buffer
> filled after sending connect command. And looking at stdio operations that
> can occur after sending the command:
>
> - fprintfs on stderr (debug mode only).
> - fgetc()s on unbuffered version.

I was worried about the "capabilities" loop in get_helper() if it reads too much from data->out (causing helper->out to lose the beginning of what it should read), but as you said, by "Causality" it cannot happen. The protocol during that phase works with the other end in lock-step, and the other end wouldn't have written to the pipe what we shouldn't read in that loop (e.g. remote-curl.c responds with "capabilities" with lines and ends with fflush(), and after that it waits for us to talk to it --- it would never start talking by itself without first being asked to talk).

Is data->out only used inside get_helper() to read the capabilities response? I was confused by it being keft open until disconnect time.