From: Jeff King <peff@peff.net>
Date: Tue, 01 Sep 2015 22:17:05 GMT
Subject: Re: [PATCH 1/2] run-command: provide in_async query function
Message-ID: <20150901221705.GA7862@sigill.intra.peff.net>
In-Reply-To: <xmqq613trdu3.fsf@gitster.mtv.corp.google.com>

On Tue, Sep 01, 2015 at 03:09:56PM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > It's not easy for arbitrary code to find out whether it is
> > running in an async process or not. A top-level function
> > which is fed to start_async() can know (you just pass down
> > an argument saying "you are async"). But that function may
> > call other global functions, and we would not want to have
> > to pass the information all the way through the call stack.
> >
> > Nor can we simply set a global variable, as those may be
> > shared between async threads and the main thread (if the
> > platform supports pthreads). We need pthread tricks _or_ a
> > global variable, depending on how start_async is
> > implemented.
> >
> > The callers don't have enough information to do this right,
> > so let's provide a simple query function that does.
> > Fortunately we can reuse the existing infrastructure to make
> > the pthread case simple (and even simplify die_async() by
> > using our new function).
> >
> > Signed-off-by: Jeff King <peff@peff.net>
> > ---
> 
> What is not immediately obvious from the above description is why a
> code may want to care if it is in_async() in the first place.
> 
> If there weren't the die_async() update, the readers might have been
> left utterly baffled (or they can somehow see this is related to
> 2/2) but it is a bit hard to arrange in "git log" as going to child
> is harder.
> 
> The patch looks good.  Thanks.

Yeah, I almost mentioned "...in the next patch we'll need this", but I
wasn't sure how to bring that up without going into the complicated
reasoning in that patch. I don't know if it's worth adding "we don't
have any callers yet, but we will add one in a moment".

-Peff