From: Junio C Hamano <gitster@pobox.com>
To: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Cc: git@vger.kernel.org, Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Subject: Re: [PATCH v3 3/3] index-pack: support multithreaded delta resolving
Date: Fri, 04 May 2012 08:23:18 -0700 [thread overview]
Message-ID: <7v8vh8c6mx.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <CACsJy8DHtBZdhoh1BPwn2_-3wVDRWypJOg3kR9wjd2o1bLUW-Q@mail.gmail.com> (Nguyen Thai Ngoc Duy's message of "Fri, 4 May 2012 19:50:26 +0700")
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> Junio, can you make a patch (or update current ones) with better
> naming? I obviously did not see why these names were bad. You may
> provide more convincing explanation than me in the commit message.
I have already explained s/nr_processed/nr_dispatched/.
I do not think second_pass vs threaded_second_pass is merely a naming
issue. The code structure ("taking the abstraction backwards") is the
bigger issue.
The original before the series has:
parse_pack_objects()
{
... a lot of code for the first pass ...
... a lot of code for the second pass which looks like
for (all object entries) {
set global state base_obj->obj to it
find unresolved deltas for that single base_obj
display progress
}
}
and you first split one iteration of the second pass, resulting in
parse_pack_objects()
{
... a lot of code for the first pass ...
for (all object entries) {
set global state base_obj->obj to it
second_pass()
}
}
which I think is a wrong way to do it, because here is what your next step
ends up with because of that:
parse_pack_objects()
{
... a lot of code for the first pass ...
#if WE SUPPORT THREADING
for (number of threads we are going to spawn) {
spawn thread and let it run threaded_second_pass
}
for (all threads) {
cull them when they are done
}
return
#endif
... when not threading ...
run threaded_second_pass() in the main process
}
It could (and should) be like this instead from the beginning, I think:
parse_pack_objects()
{
... a lot of code for the first pass ...
second_pass()
}
to encapsulate the whole second_pass() logic in the refactored function,
whose implementation (i.e. how the objects to be processed are picked up
and worked on) will change in the threaded version. In the first
refactoring patch, second_pass() would still iterate over object entries:
second_pass()
{
for (all object entries) {
resolve_deltas(base_obj)
}
}
And at this point, introduce a helper function "resolve_deltas(base)"
or something that is your "second_pass()". This deals with only one
family of objects that use the given object as their (recursive) base
objects, and use it in the above loop.
And then multi-threading support can turn that into something like
second_pass()
{
#if WE SUPPORT THREADING
for (number of threads we are going to spawn) {
spawn thread and let it run threaded_second_pass
}
for (all threads) {
cull them when they are done
}
return
#endif
... when not threading ...
for (all object entries) {
resolve_deltas(base_obj)
}
}
to add support for threaded case. The threaded_second_pass function does
only one thing and one thing well:
threaded_second_pass()
{
set thread local
loop forever {
take work item under critical section
break if there is no more work
resolve_deltas(the work item)
}
}
Wouldn't the result be much more readable that way?
You may have saved a few lines by making unthreaded code call your
threaded_second_pass() and pretend that the single main process still has
to pick up a work item and work on it in a loop like you did, but I think
it made the logic unnecessarily harder to follow.
next prev parent reply other threads:[~2012-05-04 15:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-11 5:49 [PATCH v3 0/3] Multithread index-pack Nguyễn Thái Ngọc Duy
2012-04-11 5:49 ` [PATCH v3 1/3] compat/win32/pthread.h: Add an pthread_key_delete() implementation Nguyễn Thái Ngọc Duy
2012-04-11 5:49 ` [PATCH v3 2/3] index-pack: split second pass obj handling into own function Nguyễn Thái Ngọc Duy
2012-04-11 5:49 ` [PATCH v3 3/3] index-pack: support multithreaded delta resolving Nguyễn Thái Ngọc Duy
2012-05-03 22:10 ` Junio C Hamano
2012-05-04 6:21 ` Junio C Hamano
2012-05-04 12:50 ` Nguyen Thai Ngoc Duy
2012-05-04 15:23 ` Junio C Hamano [this message]
2012-05-06 12:31 ` [PATCH 1/4] compat/win32/pthread.h: Add an pthread_key_delete() implementation Nguyễn Thái Ngọc Duy
2012-05-06 12:31 ` [PATCH 2/4] index-pack: restructure pack processing into three main functions Nguyễn Thái Ngọc Duy
2012-05-08 0:19 ` Junio C Hamano
2012-05-06 12:31 ` [PATCH 3/4] index-pack: support multithreaded delta resolving Nguyễn Thái Ngọc Duy
2012-05-06 12:31 ` [PATCH 4/4] index-pack: disable threading if NO_PREAD is defined Nguyễn Thái Ngọc Duy
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=7v8vh8c6mx.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=pclouds@gmail.com \
--cc=ramsay@ramsay1.demon.co.uk \
/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).