Re: [PATCH] Refactor recv_sideband()

From: Nicolas Pitre <nico@fluxnic.net>
Date: Jun 14, 2016, 20:10 UTC
Message-ID: <alpine.LFD.2.20.1606141600470.1714@knanqh.ubzr>
In-Reply-To: <Ct7VbfLfTHEALCt7Wbh8Xs@videotron.ca>

On Tue, 14 Jun 2016, Lukas Fleischer wrote:

Show 14 quoted lines

> On Tue, 14 Jun 2016 at 19:55:06, Nicolas Pitre wrote:
> > It is not buffered as it writes to stderr. And some C libs do separate 
> > calls to write() for every string format specifier. So "%s%s%c" may end 
> > up calling write() 3 times depending on the implementation.  The example 
> > I gave in commit ed1902ef5c is real and I even observed it with strace 
> > back then.
> 
> Ah, right, it is not buffered. Forgot that we are talking about stderr.
> 
> I still do not see how that could become a real problem, though. Apart 
> from the (purely theoretical?) performance issue, the only way 
> multiple write() calls could become a problem is when a single 
> fprintf() invocation is interrupted between two write() invocations 
> and then, there is a write() call from another thread, right?

Right. More another process in this case.

> I do not know whether we print to stderr from different threads but 
> even then, each fprintf() invocation should be atomic if I do not 
> misinterpret the POSIX specification. Could you please clarify? Are 
> there separate processes involved?

Yes, the intermixed writes come from another process such as git-index-pack via git-fetch-pack.

Nicolas