* [PATCH v3] Add git-grep threads param
@ 2015-10-26 12:32 Victor Leschuk
2015-10-26 19:32 ` John Keeping
[not found] ` <CA+55aFwrU25x25XrRODgS1oRXqN60rmYPiXLgfs3mqRco4Oi9A@mail.gmail.com>
0 siblings, 2 replies; 7+ messages in thread
From: Victor Leschuk @ 2015-10-26 12:32 UTC (permalink / raw)
To: git; +Cc: Victor Leschuk
Make number of git-grep worker threads a configuration parameter.
According to several tests on systems with different number of CPU cores
the hard-coded number of 8 threads is not optimal for all systems:
tuning this parameter can significantly speed up grep performance.
Signed-off-by: Victor Leschuk <vleschuk@accesssoftek.com>
---
Documentation/config.txt | 4 ++++
Documentation/git-grep.txt | 4 ++++
builtin/grep.c | 34 ++++++++++++++++++++++++++--------
contrib/completion/git-completion.bash | 1 +
grep.c | 10 ++++++++++
grep.h | 2 ++
6 files changed, 47 insertions(+), 8 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 391a0c3..1c95587 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1447,6 +1447,10 @@ grep.extendedRegexp::
option is ignored when the 'grep.patternType' option is set to a value
other than 'default'.
+grep.threads::
+ Number of grep worker threads, use it to tune up performance on
+ multicore machines. Default value is 8.
+
gpg.program::
Use this custom program instead of "gpg" found on $PATH when
making or verifying a PGP signature. The program must support the
diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
index 4a44d6d..fbd4f83 100644
--- a/Documentation/git-grep.txt
+++ b/Documentation/git-grep.txt
@@ -22,6 +22,7 @@ SYNOPSIS
[--color[=<when>] | --no-color]
[--break] [--heading] [-p | --show-function]
[-A <post-context>] [-B <pre-context>] [-C <context>]
+ [--threads <num>]
[-W | --function-context]
[-f <file>] [-e] <pattern>
[--and|--or|--not|(|)|-e <pattern>...]
@@ -220,6 +221,9 @@ OPTIONS
Show <num> leading lines, and place a line containing
`--` between contiguous groups of matches.
+--threads <num>::
+ Set number of worker threads to <num>. Default is 8.
+
-W::
--function-context::
Show the surrounding text from the previous line containing a
diff --git a/builtin/grep.c b/builtin/grep.c
index d04f440..5ef1b07 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -27,8 +27,7 @@ static char const * const grep_usage[] = {
static int use_threads = 1;
#ifndef NO_PTHREADS
-#define THREADS 8
-static pthread_t threads[THREADS];
+static pthread_t *threads;
/* We use one producer thread and THREADS consumer
* threads. The producer adds struct work_items to 'todo' and the
@@ -206,7 +205,8 @@ static void start_threads(struct grep_opt *opt)
strbuf_init(&todo[i].out, 0);
}
- for (i = 0; i < ARRAY_SIZE(threads); i++) {
+ threads = xcalloc(opt->num_threads, sizeof(pthread_t));
+ for (i = 0; i < opt->num_threads; i++) {
int err;
struct grep_opt *o = grep_opt_dup(opt);
o->output = strbuf_out;
@@ -220,7 +220,7 @@ static void start_threads(struct grep_opt *opt)
}
}
-static int wait_all(void)
+static int wait_all(struct grep_opt *opt)
{
int hit = 0;
int i;
@@ -238,12 +238,14 @@ static int wait_all(void)
pthread_cond_broadcast(&cond_add);
grep_unlock();
- for (i = 0; i < ARRAY_SIZE(threads); i++) {
+ for (i = 0; i < opt->num_threads; i++) {
void *h;
pthread_join(threads[i], &h);
hit |= (int) (intptr_t) h;
}
+ free(threads);
+
pthread_mutex_destroy(&grep_mutex);
pthread_mutex_destroy(&grep_read_mutex);
pthread_mutex_destroy(&grep_attr_mutex);
@@ -256,7 +258,7 @@ static int wait_all(void)
}
#else /* !NO_PTHREADS */
-static int wait_all(void)
+static int wait_all(struct grep_opt *opt)
{
return 0;
}
@@ -702,6 +704,8 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
N_("show <n> context lines before matches")),
OPT_INTEGER('A', "after-context", &opt.post_context,
N_("show <n> context lines after matches")),
+ OPT_INTEGER(0, "threads", &opt.num_threads,
+ N_("use <n> worker threads")),
OPT_NUMBER_CALLBACK(&opt, N_("shortcut for -C NUM"),
context_callback),
OPT_BOOL('p', "show-function", &opt.funcname,
@@ -832,8 +836,22 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
}
#ifndef NO_PTHREADS
- if (list.nr || cached || online_cpus() == 1)
+ if (!opt.num_threads) {
+ use_threads = 0; /* User explicitely told not to use threads */
+ }
+ else if (list.nr || cached) {
+ use_threads = 0; /* Can not multi-thread object lookup */
+ }
+ else if (opt.num_threads >= 0) {
+ use_threads = 1; /* User explicitely set the number of threads */
+ }
+ else if (online_cpus() <= 1) {
use_threads = 0;
+ }
+ else {
+ use_threads = 1;
+ opt.num_threads = GREP_NUM_THREADS_DEFAULT;
+ }
#else
use_threads = 0;
#endif
@@ -910,7 +928,7 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
}
if (use_threads)
- hit |= wait_all();
+ hit |= wait_all(&opt);
if (hit && show_in_pager)
run_pager(&opt, prefix);
free_grep_patterns(&opt);
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 482ca84..390d9c0 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1310,6 +1310,7 @@ _git_grep ()
--full-name --line-number
--extended-regexp --basic-regexp --fixed-strings
--perl-regexp
+ --threads
--files-with-matches --name-only
--files-without-match
--max-depth
diff --git a/grep.c b/grep.c
index 7b2b96a..b53fb14 100644
--- a/grep.c
+++ b/grep.c
@@ -40,6 +40,7 @@ void init_grep_defaults(void)
color_set(opt->color_selected, "");
color_set(opt->color_sep, GIT_COLOR_CYAN);
opt->color = -1;
+ opt->num_threads = -1;
}
static int parse_pattern_type_arg(const char *opt, const char *arg)
@@ -124,6 +125,14 @@ int grep_config(const char *var, const char *value, void *cb)
return config_error_nonbool(var);
return color_parse(value, color);
}
+
+ if (!strcmp(var, "grep.threads")) {
+ int threads = git_config_int(var, value);
+ if (threads < 0)
+ die("invalid number of threads specified (%d)", threads);
+ opt->num_threads = threads;
+ return 0;
+ }
return 0;
}
@@ -150,6 +159,7 @@ void grep_init(struct grep_opt *opt, const char *prefix)
opt->pathname = def->pathname;
opt->regflags = def->regflags;
opt->relative = def->relative;
+ opt->num_threads = def->num_threads;
color_set(opt->color_context, def->color_context);
color_set(opt->color_filename, def->color_filename);
diff --git a/grep.h b/grep.h
index 95f197a..bb20456 100644
--- a/grep.h
+++ b/grep.h
@@ -132,6 +132,8 @@ struct grep_opt {
unsigned pre_context;
unsigned post_context;
unsigned last_shown;
+#define GREP_NUM_THREADS_DEFAULT 8
+ int num_threads;
int show_hunk_mark;
int file_break;
int heading;
--
2.6.2.281.g222e106.dirty
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH v3] Add git-grep threads param
2015-10-26 12:32 [PATCH v3] Add git-grep threads param Victor Leschuk
@ 2015-10-26 19:32 ` John Keeping
2015-10-27 5:25 ` Victor Leschuk
[not found] ` <CA+55aFwrU25x25XrRODgS1oRXqN60rmYPiXLgfs3mqRco4Oi9A@mail.gmail.com>
1 sibling, 1 reply; 7+ messages in thread
From: John Keeping @ 2015-10-26 19:32 UTC (permalink / raw)
To: Victor Leschuk; +Cc: git, Victor Leschuk
On Mon, Oct 26, 2015 at 03:32:13PM +0300, Victor Leschuk wrote:
> Make number of git-grep worker threads a configuration parameter.
> According to several tests on systems with different number of CPU cores
> the hard-coded number of 8 threads is not optimal for all systems:
> tuning this parameter can significantly speed up grep performance.
>
> Signed-off-by: Victor Leschuk <vleschuk@accesssoftek.com>
> ---
> Documentation/config.txt | 4 ++++
> Documentation/git-grep.txt | 4 ++++
> builtin/grep.c | 34 ++++++++++++++++++++++++++--------
> contrib/completion/git-completion.bash | 1 +
> grep.c | 10 ++++++++++
> grep.h | 2 ++
> 6 files changed, 47 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 391a0c3..1c95587 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1447,6 +1447,10 @@ grep.extendedRegexp::
> option is ignored when the 'grep.patternType' option is set to a value
> other than 'default'.
>
> +grep.threads::
> + Number of grep worker threads, use it to tune up performance on
> + multicore machines. Default value is 8.
> +
> gpg.program::
> Use this custom program instead of "gpg" found on $PATH when
> making or verifying a PGP signature. The program must support the
> diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
> index 4a44d6d..fbd4f83 100644
> --- a/Documentation/git-grep.txt
> +++ b/Documentation/git-grep.txt
> @@ -22,6 +22,7 @@ SYNOPSIS
> [--color[=<when>] | --no-color]
> [--break] [--heading] [-p | --show-function]
> [-A <post-context>] [-B <pre-context>] [-C <context>]
> + [--threads <num>]
Is this the best place for this option? I know the current list isn't
sorted in any particular way, but here you're splitting up the set of
context options (`-A`, `-B`, `-C` and `-W`).
> [-W | --function-context]
> [-f <file>] [-e] <pattern>
> [--and|--or|--not|(|)|-e <pattern>...]
> @@ -220,6 +221,9 @@ OPTIONS
> Show <num> leading lines, and place a line containing
> `--` between contiguous groups of matches.
>
> +--threads <num>::
> + Set number of worker threads to <num>. Default is 8.
The same comment as above applies here.
> -W::
> --function-context::
> Show the surrounding text from the previous line containing a
> diff --git a/builtin/grep.c b/builtin/grep.c
> index d04f440..5ef1b07 100644
> --- a/builtin/grep.c
> +++ b/builtin/grep.c
> @@ -27,8 +27,7 @@ static char const * const grep_usage[] = {
> static int use_threads = 1;
>
> #ifndef NO_PTHREADS
> -#define THREADS 8
> -static pthread_t threads[THREADS];
> +static pthread_t *threads;
>
> /* We use one producer thread and THREADS consumer
> * threads. The producer adds struct work_items to 'todo' and the
> @@ -206,7 +205,8 @@ static void start_threads(struct grep_opt *opt)
> strbuf_init(&todo[i].out, 0);
> }
>
> - for (i = 0; i < ARRAY_SIZE(threads); i++) {
> + threads = xcalloc(opt->num_threads, sizeof(pthread_t));
> + for (i = 0; i < opt->num_threads; i++) {
> int err;
> struct grep_opt *o = grep_opt_dup(opt);
> o->output = strbuf_out;
> @@ -220,7 +220,7 @@ static void start_threads(struct grep_opt *opt)
> }
> }
>
> -static int wait_all(void)
> +static int wait_all(struct grep_opt *opt)
I'm not sure passing a grep_opt in here is the cleanest way to do this.
Options are a UI concept and all we care about here is the number of
threads.
Since `threads` is a global, shouldn't the number of threads be a global
as well? Could we reuse `use_threads` here (possibly renaming it
`num_threads`)?
> {
> int hit = 0;
> int i;
> @@ -238,12 +238,14 @@ static int wait_all(void)
> pthread_cond_broadcast(&cond_add);
> grep_unlock();
>
> - for (i = 0; i < ARRAY_SIZE(threads); i++) {
> + for (i = 0; i < opt->num_threads; i++) {
> void *h;
> pthread_join(threads[i], &h);
> hit |= (int) (intptr_t) h;
> }
>
> + free(threads);
> +
> pthread_mutex_destroy(&grep_mutex);
> pthread_mutex_destroy(&grep_read_mutex);
> pthread_mutex_destroy(&grep_attr_mutex);
> @@ -256,7 +258,7 @@ static int wait_all(void)
> }
> #else /* !NO_PTHREADS */
>
> -static int wait_all(void)
> +static int wait_all(struct grep_opt *opt)
> {
> return 0;
> }
> @@ -702,6 +704,8 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
> N_("show <n> context lines before matches")),
> OPT_INTEGER('A', "after-context", &opt.post_context,
> N_("show <n> context lines after matches")),
> + OPT_INTEGER(0, "threads", &opt.num_threads,
> + N_("use <n> worker threads")),
> OPT_NUMBER_CALLBACK(&opt, N_("shortcut for -C NUM"),
> context_callback),
> OPT_BOOL('p', "show-function", &opt.funcname,
> @@ -832,8 +836,22 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
> }
>
> #ifndef NO_PTHREADS
> - if (list.nr || cached || online_cpus() == 1)
> + if (!opt.num_threads) {
> + use_threads = 0; /* User explicitely told not to use threads */
> + }
> + else if (list.nr || cached) {
> + use_threads = 0; /* Can not multi-thread object lookup */
> + }
> + else if (opt.num_threads >= 0) {
> + use_threads = 1; /* User explicitely set the number of threads */
> + }
> + else if (online_cpus() <= 1) {
> use_threads = 0;
> + }
> + else {
> + use_threads = 1;
> + opt.num_threads = GREP_NUM_THREADS_DEFAULT;
> + }
> #else
> use_threads = 0;
> #endif
> @@ -910,7 +928,7 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
> }
>
> if (use_threads)
> - hit |= wait_all();
> + hit |= wait_all(&opt);
> if (hit && show_in_pager)
> run_pager(&opt, prefix);
> free_grep_patterns(&opt);
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 482ca84..390d9c0 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -1310,6 +1310,7 @@ _git_grep ()
> --full-name --line-number
> --extended-regexp --basic-regexp --fixed-strings
> --perl-regexp
> + --threads
> --files-with-matches --name-only
> --files-without-match
> --max-depth
> diff --git a/grep.c b/grep.c
> index 7b2b96a..b53fb14 100644
> --- a/grep.c
> +++ b/grep.c
> @@ -40,6 +40,7 @@ void init_grep_defaults(void)
> color_set(opt->color_selected, "");
> color_set(opt->color_sep, GIT_COLOR_CYAN);
> opt->color = -1;
> + opt->num_threads = -1;
> }
>
> static int parse_pattern_type_arg(const char *opt, const char *arg)
> @@ -124,6 +125,14 @@ int grep_config(const char *var, const char *value, void *cb)
> return config_error_nonbool(var);
> return color_parse(value, color);
> }
> +
> + if (!strcmp(var, "grep.threads")) {
> + int threads = git_config_int(var, value);
> + if (threads < 0)
> + die("invalid number of threads specified (%d)", threads);
> + opt->num_threads = threads;
> + return 0;
> + }
> return 0;
> }
>
> @@ -150,6 +159,7 @@ void grep_init(struct grep_opt *opt, const char *prefix)
> opt->pathname = def->pathname;
> opt->regflags = def->regflags;
> opt->relative = def->relative;
> + opt->num_threads = def->num_threads;
>
> color_set(opt->color_context, def->color_context);
> color_set(opt->color_filename, def->color_filename);
> diff --git a/grep.h b/grep.h
> index 95f197a..bb20456 100644
> --- a/grep.h
> +++ b/grep.h
> @@ -132,6 +132,8 @@ struct grep_opt {
> unsigned pre_context;
> unsigned post_context;
> unsigned last_shown;
> +#define GREP_NUM_THREADS_DEFAULT 8
> + int num_threads;
> int show_hunk_mark;
> int file_break;
> int heading;
> --
> 2.6.2.281.g222e106.dirty
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: [PATCH v3] Add git-grep threads param
2015-10-26 19:32 ` John Keeping
@ 2015-10-27 5:25 ` Victor Leschuk
2015-10-27 11:52 ` John Keeping
0 siblings, 1 reply; 7+ messages in thread
From: Victor Leschuk @ 2015-10-27 5:25 UTC (permalink / raw)
To: John Keeping, Victor Leschuk; +Cc: git@vger.kernel.org
Hello John,
see comments inline.
>> @@ -22,6 +22,7 @@ SYNOPSIS
>> [--color[=<when>] | --no-color]
>> [--break] [--heading] [-p | --show-function]
>> [-A <post-context>] [-B <pre-context>] [-C <context>]
>> + [--threads <num>]
> Is this the best place for this option? I know the current list isn't
> sorted in any particular way, but here you're splitting up the set of
> context options (`-A`, `-B`, `-C` and `-W`).
Agree, I'll move the option both here and in documentation.
>> -static int wait_all(void)
>> +static int wait_all(struct grep_opt *opt)
> I'm not sure passing a grep_opt in here is the cleanest way to do this.
> Options are a UI concept and all we care about here is the number of
> threads.
> Since `threads` is a global, shouldn't the number of threads be a global
> as well? Could we reuse `use_threads` here (possibly renaming it
> `num_threads`)?
This thought also crossed my mind, however we already pass grep_opt to start_threads() function,
so I think passing it to wait_all() is not that ugly, and kind of symmetric. And I do not like the idea
of duplicating same information in different places. What do you think?
--
Best Regards,
Victor
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: [PATCH v3] Add git-grep threads param
[not found] ` <CA+55aFwrU25x25XrRODgS1oRXqN60rmYPiXLgfs3mqRco4Oi9A@mail.gmail.com>
@ 2015-10-27 9:14 ` Victor Leschuk
0 siblings, 0 replies; 7+ messages in thread
From: Victor Leschuk @ 2015-10-27 9:14 UTC (permalink / raw)
To: Linus Torvalds, Victor Leschuk; +Cc: Git Mailing List
Hello Linus,
>> According to several tests on systems with different number of CPU cores
>> the hard-coded number of 8 threads is not optimal for all systems:
> Did you also compare cold-cache filesystem performance?
> One of the reasons for doing threaded grep is for CPU scaling. But another is for IO scaling. If your git tree is over NFS, doing grep eight threads at a time if likely going to make things much faster even if you are on a single CPU.
Yes, I have performed tests on cold-cache FS and it looks like number of threads affects performance. Here are the results for grepping linux kernel repo on a 4-core machine (similar test was conducted on 8-core machine):
Threads: 4 Time: 39.13
Threads: 8 Time: 34.39
Threads: 16 Time: 31.46
Threads: 32 Time: 27.40
Here is test scenario:
#!/bin/bash
TIMEFORMAT=%R
GIT=/home/del/git-dev/bin/git
TESTS=10
for n in 4 8 16 32; do
echo -n "Threads: $n Time: "
for i in $(seq 1 $TESTS); do
echo 3 > /proc/sys/vm/drop_caches
time $GIT grep --threads $n -e '#define' --and \( -e MAX_PATH -e PATH_MAX \) >/dev/null
done 2>&1 | awk -v ntests=${TESTS} '{sum+=$1} END{printf "%.2f\n", sum/ntests}'
done
Note: With hot-cache grepping with 4 threads gives fastest results on both 4-core and 8-core machines.
Thus I think it can be useful for users to be able to tune the threads number according to their needs.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v3] Add git-grep threads param
2015-10-27 5:25 ` Victor Leschuk
@ 2015-10-27 11:52 ` John Keeping
2015-10-27 13:54 ` Victor Leschuk
0 siblings, 1 reply; 7+ messages in thread
From: John Keeping @ 2015-10-27 11:52 UTC (permalink / raw)
To: Victor Leschuk; +Cc: Victor Leschuk, git@vger.kernel.org
On Mon, Oct 26, 2015 at 10:25:41PM -0700, Victor Leschuk wrote:
> >> @@ -22,6 +22,7 @@ SYNOPSIS
> >> [--color[=<when>] | --no-color]
> >> [--break] [--heading] [-p | --show-function]
> >> [-A <post-context>] [-B <pre-context>] [-C <context>]
> >> + [--threads <num>]
>
> > Is this the best place for this option? I know the current list isn't
> > sorted in any particular way, but here you're splitting up the set of
> > context options (`-A`, `-B`, `-C` and `-W`).
>
> Agree, I'll move the option both here and in documentation.
>
> >> -static int wait_all(void)
> >> +static int wait_all(struct grep_opt *opt)
>
> > I'm not sure passing a grep_opt in here is the cleanest way to do this.
> > Options are a UI concept and all we care about here is the number of
> > threads.
>
> > Since `threads` is a global, shouldn't the number of threads be a global
> > as well? Could we reuse `use_threads` here (possibly renaming it
> > `num_threads`)?
>
> This thought also crossed my mind, however we already pass grep_opt to
> start_threads() function, so I think passing it to wait_all() is not
> that ugly, and kind of symmetric. And I do not like the idea of
> duplicating same information in different places. What do you think?
The grep_opt in start_threads() is being passed through to run(), so it
seems slightly different to me. If the threads were being setup in
grep.c (as opposed to builtin/grep.c) then I'd agree that it belongs in
grep_opt, but since this is local to this particular user of the grep
infrastructure adding num_threads to the grep_opt structure at all feels
wrong to me.
Note that I wasn't suggesting passing num_threads as a parameter to
wait_all(), but rather having it as global state that is accessed by
wait_all() in the same way as the `threads` array.
If we rename use_threads to num_threads and just use that, then we only
have the information in one place don't we?
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: [PATCH v3] Add git-grep threads param
2015-10-27 11:52 ` John Keeping
@ 2015-10-27 13:54 ` Victor Leschuk
2015-10-27 14:11 ` John Keeping
0 siblings, 1 reply; 7+ messages in thread
From: Victor Leschuk @ 2015-10-27 13:54 UTC (permalink / raw)
To: John Keeping; +Cc: Victor Leschuk, git@vger.kernel.org
Hello John,
>> This thought also crossed my mind, however we already pass grep_opt to
>> start_threads() function, so I think passing it to wait_all() is not
>> that ugly, and kind of symmetric. And I do not like the idea of
>> duplicating same information in different places. What do you think?
> The grep_opt in start_threads() is being passed through to run(), so it
> seems slightly different to me. If the threads were being setup in
> grep.c (as opposed to builtin/grep.c) then I'd agree that it belongs in
> grep_opt, but since this is local to this particular user of the grep
> infrastructure adding num_threads to the grep_opt structure at all feels
> wrong to me.
> Note that I wasn't suggesting passing num_threads as a parameter to
> wait_all(), but rather having it as global state that is accessed by
> wait_all() in the same way as the `threads` array.
> If we rename use_threads to num_threads and just use that, then we only
> have the information in one place don't we?
Yeah, I understood your idea. So we parse config_value directly to
static int num_threads; /* old use_threads */
And use it internally in builtin/grep.c. I think you are right.
Looks like grep_cmd_config() is the right place to parse it. Something like:
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -267,6 +267,8 @@ static int wait_all(struct grep_opt *opt)
static int grep_cmd_config(const char *var, const char *value, void *cb)
{
int st = grep_config(var, value, cb);
+ if (thread_config(var, value, cb) < 0)
+ st = -1;
if (git_color_default_config(var, value, cb) < 0)
st = -1;
return st;
What do you think?
--
Best Regards,
Victor
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v3] Add git-grep threads param
2015-10-27 13:54 ` Victor Leschuk
@ 2015-10-27 14:11 ` John Keeping
0 siblings, 0 replies; 7+ messages in thread
From: John Keeping @ 2015-10-27 14:11 UTC (permalink / raw)
To: Victor Leschuk; +Cc: Victor Leschuk, git@vger.kernel.org
On Tue, Oct 27, 2015 at 06:54:16AM -0700, Victor Leschuk wrote:
> Hello John,
>
> >> This thought also crossed my mind, however we already pass grep_opt to
> >> start_threads() function, so I think passing it to wait_all() is not
> >> that ugly, and kind of symmetric. And I do not like the idea of
> >> duplicating same information in different places. What do you think?
>
> > The grep_opt in start_threads() is being passed through to run(), so it
> > seems slightly different to me. If the threads were being setup in
> > grep.c (as opposed to builtin/grep.c) then I'd agree that it belongs in
> > grep_opt, but since this is local to this particular user of the grep
> > infrastructure adding num_threads to the grep_opt structure at all feels
> > wrong to me.
>
> > Note that I wasn't suggesting passing num_threads as a parameter to
> > wait_all(), but rather having it as global state that is accessed by
> > wait_all() in the same way as the `threads` array.
>
> > If we rename use_threads to num_threads and just use that, then we only
> > have the information in one place don't we?
>
> Yeah, I understood your idea. So we parse config_value directly to
>
> static int num_threads; /* old use_threads */
Presumably this is:
static int num_threads = -1;
so that the default behaviour continues to work correctly.
> And use it internally in builtin/grep.c. I think you are right.
>
> Looks like grep_cmd_config() is the right place to parse it. Something like:
>
> --- a/builtin/grep.c
> +++ b/builtin/grep.c
> @@ -267,6 +267,8 @@ static int wait_all(struct grep_opt *opt)
> static int grep_cmd_config(const char *var, const char *value, void *cb)
> {
> int st = grep_config(var, value, cb);
> + if (thread_config(var, value, cb) < 0)
> + st = -1;
> if (git_color_default_config(var, value, cb) < 0)
> st = -1;
> return st;
>
> What do you think?
I'd be tempted to open code the "grep.threads" case in this function
rather than introducing a helper for a single variable, but I don't
think it matters either way. This looks good.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-10-27 14:11 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-10-26 12:32 [PATCH v3] Add git-grep threads param Victor Leschuk
2015-10-26 19:32 ` John Keeping
2015-10-27 5:25 ` Victor Leschuk
2015-10-27 11:52 ` John Keeping
2015-10-27 13:54 ` Victor Leschuk
2015-10-27 14:11 ` John Keeping
[not found] ` <CA+55aFwrU25x25XrRODgS1oRXqN60rmYPiXLgfs3mqRco4Oi9A@mail.gmail.com>
2015-10-27 9:14 ` Victor Leschuk
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).