Stefan Beller <sbel...@google.com> writes: > That's why I want to be a bit more generic and have this thread pool API > done in C, such that "any for loop" in git can be easily replaced by using > the thread pool. I think of "git fetch --all" specially.
One more thing, as I didn't notice that you kept repeating "thread" pool API. While I doubt that you would gain much by using threads in place of processes to perform parallel "submodule update", "submodule clone", "fetch all", etc., all of which are fairly well isolated and heavy weight operations themselves, and I suspect that the implementation simplicity of using separate processes would probably be huge plus compared to any possible upside you may gain from using threads, if you really want to go the "thread" route, the first thing to try would be to see if a few places we already use threads for parallelism (namely, "grep", "pack-objects", "preload-index" and "index-pack") can be factored out and model your new API around the commonality among them. -- 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
