On Fri, Dec 9, 2011 at 3:39 PM, Thomas Rast <trast@xxxxxxxxxxxxxxx> wrote: > More precisely speaking, this pushes the locking down from > read_object() into bits of the pack machinery that cannot (yet) run in > parallel. > > There are several hacks here: > > a) prepare_packed_git() must be called before any parallel accesses > happen. It now unconditionally opens and maps all index files. > > b) similarly, prepare_replace_object() must be called before any > parallel read_sha1_file() happens > > This simplification lets us avoid locking outright to guard the index > accesses; locking is then mainly required for open_packed_git(), > [un]use_pack(), and such. > > The ultimate goal would of course be to let at least _some_ pack > accesses happen without any locking whatsoever. But grep already > benefits from it with a nice speed boost on non-worktree greps. (I'm running into multithread pack access problem in rev-list..) Why not put the global pointer "struct packed_git *packed_git" to "struct pack_context" and avoid locking entirely? Resource usage is like we run <n> different processes, I think, which is not too bad. We may want to share a few static pack_* variables such as pack_open_fds.. to avoid hitting system limits too fast. -- Duy -- 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