On Tue, Sep 01, 2015 at 03:13:25PM -0700, Junio C Hamano wrote: > > So instead, let us just assume that any async process is > > handling sideband data. That's always true now, and is > > likely to remain so in the future. > > Hmm, does Stefan's thread-pool thing interact with this decision in > any way?
I don't think so. It is true that: start_async(...); finish_async(...); pthread_create(foo); would incorrectly report in_async() inside the foo function (because we know that async has been kicked off, and we know that we are in a thread that is not the main one). But I don't think it matters in the current code base, because we tend to use async for I/O tasks like muxing/demuxing, and real threads in CPU-heavy tasks like pack-objects. Still, I admit it is a little gross, and may be a problem in the future. An alternate approach would be to have the async system provide a thread-local storage abstraction. With pthreads, we'd build on pthread_setspecific(), and without, it becomes a simple global variable. That's more work, but a lot less error-prone, and it may come in handy in the future. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
