On Tue, Sep 01, 2015 at 03:09:56PM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> 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@xxxxxxxx> > > --- > > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html