grep: allow submodule functions to run in parallel
authorMatheus Tavares <matheus.bernardino@usp.br>
Thu, 16 Jan 2020 02:39:56 +0000 (23:39 -0300)
committerJunio C Hamano <gitster@pobox.com>
Fri, 17 Jan 2020 21:52:14 +0000 (13:52 -0800)
commitc441ea4edcba135c60c095b5d8b4517a87890b34
tree8910c7ed605979cd8f048d600ab189fa2a18374f
parentd7992421e1a0e3ea5f836d8906e0f8b197fb6c1e
grep: allow submodule functions to run in parallel

Now that object reading operations are internally protected, the
submodule initialization functions at builtin/grep.c:grep_submodule()
are very close to being thread-safe. Let's take a look at each call and
remove from the critical section what we can, for better performance:

- submodule_from_path() and is_submodule_active() cannot be called in
  parallel yet only because they call repo_read_gitmodules() which
  contains, in its call stack, operations that would otherwise be in
  race condition with object reading (for example parse_object() and
  is_promisor_remote()). However, they only call repo_read_gitmodules()
  if it wasn't read before. So let's pre-read it before firing the
  threads and allow these two functions to safely be called in
  parallel.

- repo_submodule_init() is already thread-safe, so remove it from the
  critical section without other necessary changes.

- The repo_read_gitmodules(&subrepo) call at grep_submodule() is safe as
  no other thread is performing object reading operations in the subrepo
  yet. However, threads might be working in the superproject, and this
  function calls add_to_alternates_memory() internally, which is racy
  with object readings in the superproject. So it must be kept
  protected for now. Let's add a "NEEDSWORK" to it, informing why it
  cannot be removed from the critical section yet.

- Finally, add_to_alternates_memory() must be kept protected for the
  same reason as the item above.

Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/grep.c