From: Stefan Beller <sbeller@google.com>
To: Johannes Sixt <j6t@kdbg.org>
Cc: Junio C Hamano <gitster@pobox.com>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: sb/submodule-parallel-fetch, was: Re: What's cooking in git.git (Dec 2015, #03; Thu, 10)
Date: Fri, 11 Dec 2015 14:52:53 -0800 [thread overview]
Message-ID: <CAGZ79kYOtoWHCzpeHGrCEjTUuKYB3rogfV2dxL_TL5Pcu59RSg@mail.gmail.com> (raw)
In-Reply-To: <566B4207.8020009@kdbg.org>
On Fri, Dec 11, 2015 at 1:37 PM, Johannes Sixt <j6t@kdbg.org> wrote:
>
> Generally, I'm already quite satisfied with the state of the
> infrastructure at the tip of the branch.
>
I was about the rework the patch series.
> Nevertheless, I have a few niggles.
If you don't mind I'll split your patch into chunks and
squash these where appropriate and resend the series
with the suggestions included without the intermediate stages
of non compiling code for Windows.
>
> The primary one is that we are using a global variable of type
> struct parallel_processes to keep track of the processes. Fortunately,
> most functions already take a pointer (I gather you did anticipate an
> object oriented use of the functions). The only exception is pp_init():
> It returns a pointer to the global object, which is then passed around
> to the other functions. This does not conform to our usual style,
> however, where the initializer function takes a pointer to the object,
> too.
Noted. I thought about the init function as a constructor,
such as
foo *pp = new foo();
in C++ would be just syntactic sugar for what I did there.
I'll adhere to Git style then instead.
>
> After converting pp_init, we can have a nicely object oriented
> collection of functions and get rid of the global object ... almost.
>
> We still need a global variable for the signal handler. But since
> signals and their handlers are a global resource, it is not that bad to
> have a global variable that is dedicated to signal handling.
>
> Another small nit is that I found it confusing that the closure
> parameters are arranged differently in the callback functions. Granted,
> in get_next_task one of them is an out parameter, but that is actually
> an argument to move it to the end of the parameter list, IMHO.
>
> On top of that I found an error or two in the documentation, and I have
> a few suggestions for improvements.
>
> All this is summarized in the patch below.
Thanks for the improvements!
Stefan
next prev parent reply other threads:[~2015-12-11 22:53 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-10 22:46 What's cooking in git.git (Dec 2015, #03; Thu, 10) Junio C Hamano
2015-12-10 23:25 ` Stefan Beller
2015-12-10 23:33 ` Junio C Hamano
2015-12-10 23:51 ` Junio C Hamano
2015-12-10 23:55 ` Stefan Beller
2015-12-11 17:39 ` Junio C Hamano
2015-12-11 21:37 ` sb/submodule-parallel-fetch, was: " Johannes Sixt
2015-12-11 22:52 ` Stefan Beller [this message]
2015-12-11 23:07 ` sb/submodule-parallel-fetch, Junio C Hamano
2015-12-14 19:37 ` sb/submodule-parallel-fetch, Stefan Beller
2015-12-11 23:39 ` sb/submodule-parallel-fetch, was: Re: What's cooking in git.git (Dec 2015, #03; Thu, 10) Johannes Sixt
2015-12-11 0:18 ` John Keeping
2015-12-11 17:43 ` Junio C Hamano
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=CAGZ79kYOtoWHCzpeHGrCEjTUuKYB3rogfV2dxL_TL5Pcu59RSg@mail.gmail.com \
--to=sbeller@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=j6t@kdbg.org \
/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).