Re: [PATCH 1/2] run-command: provide in_async query function
- From
Jeff King <peff@peff.net>
- Date
- Sep 1, 2015, 22:17 UTC
- 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:
Show 33 quoted lines
> 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