Re: [PATCH v2 7/8] submodule-config: pass repo upon blob config read

On Mon, Aug 16, 2021 at 11:32 AM Matheus Tavares Bernardino
[off-list ref] wrote:

On Fri, Aug 13, 2021 at 6:05 PM Jonathan Tan [off-list ref] wrote:

quoted

When reading the config of a submodule, if reading from a blob, read
using an explicitly specified repository instead of by adding the
submodule's ODB as an alternate and then reading an object from
the_repository.

Great!

At first, I thought this would also allow us to remove another
NEEDSWORK comment in grep_submodule(), together with a lock
protection:

/*
 * NEEDSWORK: repo_read_gitmodules() might call
 * add_to_alternates_memory() via config_from_gitmodules(). This
 * operation causes a race condition with concurrent object readings
 * performed by the worker threads. That's why we need obj_read_lock()
 * here. It should be removed once it's no longer necessary to add the
 * subrepo's odbs to the in-memory alternates list.
 */
obj_read_lock();
repo_read_gitmodules(subrepo, 0);

Back when I wrote this comment, my conclusion was that the alternates
mechanics were the only thread-unsafe object-reading operations in
repo_read_gitmodules()'s call chains. So once the add-to-alternates
mechanics were gone, we could also remove the lock.

But with further inspection now, I see that this is not really the
case. For example, we have a few global variables in packfile.c
collecting some statistics (pack_mmap_calls, pack_open_windows, etc.)
which are updated on obj readings from both the_repository *and*
submodules.

Sorry, this is incorrect. I forgot that repo_read_object_file() (which
is part of repo_read_gitmodules()'s call chain) also acquires the
obj_read_mutex before accessing those global variables. So the
NEEDSWORK might be right.

Nevertheless, I think it might be better to look into
repo_read_gitmodules() more carefully before removing this lock. And
this is something for another series. Sorry about the noise.