From: Junio C Hamano <gitster@pobox.com>
To: Jonathan Tan <jonathantanmy@google.com>
Cc: "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com>,
git@vger.kernel.org, me@ttaylorr.com,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Derrick Stolee" <derrickstolee@github.com>
Subject: Re: [PATCH v2] object-file: reprepare alternates when necessary
Date: Fri, 10 Mar 2023 16:01:51 -0800 [thread overview]
Message-ID: <xmqqilf8yx3k.fsf@gitster.g> (raw)
In-Reply-To: 20230310212916.4138690-1-jonathantanmy@google.com
Jonathan Tan <jonathantanmy@google.com> writes:
> But I guess clearing a linked list and hashmap can be a bit cumbersome
> in C, so maybe it would be reasonable to assume that this behavior
> would not change.
I think the original reason why we did not clear was because we
never knew (and we do not know) what is still in use. Can anybody
explain why it would be a safe thing to do to rebuild the alt-odb
list from scratch? Surely we can have a big central lock to do the
"list manipulation" part safely, but is it safe to access the
objects we obtained from one of the odb's that no longer is listed
on the alt-odb list, for example? The code that this patch touches
clears the loose object cache after updating the odb list, so loose
object cache of any odb that goes away will not be cleared here,
which means that the code that reconstruts alt-odb list would need
to clear the loose object cache automatically? What should we do to
packfiles that are mmaped from these alt-odbs that goes away? Etc.
etc.
> In any case, maybe a comment should be added to prepare_alt_odb()
> saying that if an update of the alternates is needed, one can do
> so by clearing loaded_alternates and re- invoking
> prepare_alt_odb() (at least so that a developer changing
> prepare_alt_odb() can see the comment and understand what
> behaviors this function needs to preserve).
Sounds good.
Thanks.
next prev parent reply other threads:[~2023-03-11 0:01 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-06 20:59 [PATCH] object-file: reprepare alternates when necessary Derrick Stolee via GitGitGadget
2023-03-06 22:54 ` Junio C Hamano
2023-03-07 0:28 ` Taylor Blau
2023-03-07 14:52 ` Derrick Stolee
2023-03-07 17:16 ` Junio C Hamano
2023-03-08 15:55 ` Taylor Blau
2023-03-08 17:13 ` Derrick Stolee
2023-03-07 11:28 ` Ævar Arnfjörð Bjarmason
2023-03-07 17:29 ` Junio C Hamano
2023-03-07 18:18 ` Junio C Hamano
2023-03-08 13:29 ` Derrick Stolee
2023-03-08 18:47 ` [PATCH v2] " Derrick Stolee via GitGitGadget
2023-03-08 19:35 ` Junio C Hamano
2023-03-08 20:47 ` Taylor Blau
2023-03-09 7:24 ` Jeff King
2023-03-09 9:06 ` Eric Wong
2023-03-10 21:29 ` Jonathan Tan
2023-03-11 0:01 ` Junio C Hamano [this message]
2023-03-11 3:09 ` Jonathan Tan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqilf8yx3k.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=derrickstolee@github.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=jonathantanmy@google.com \
--cc=me@ttaylorr.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).