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

Ilari Liusvaara [off-list ref] writes:

quoted

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.