> Now, git-grep could make use of the pluggable error facility added in > commit c19a490e37 ("usage: allow pluggable die-recursion checks", > 2013-04-16).
I think we should do that instead (though I have not looked at the downsides of this), because... > > So let's just set the recursion limit to a number higher than the > number of threads we're ever likely to spawn. Now we won't lose > errors, and if we have a recursing die handler we'll still die within > microseconds. how are we handling access to that global variable? Do we need to hold a mutex to be correct? or rather hope that it works across threads, not counting on it, because each thread individually would count up to 1024? I would prefer if we kept the number as low as "at most one screen of lines". > Signed-off-by: Ævar Arnfjörð Bjarmason <ava...@gmail.com> > --- > usage.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/usage.c b/usage.c > index 2f87ca69a8..1c198d4882 100644 > --- a/usage.c > +++ b/usage.c > @@ -44,7 +44,9 @@ static void warn_builtin(const char *warn, va_list params) > static int die_is_recursing_builtin(void) > { > static int dying; > - return dying++; > + static int recursion_limit = 1024; > + > + return dying++ > recursion_limit; > } > > /* If we are in a dlopen()ed .so write to a global variable would segfault > -- > 2.13.1.518.g3df882009 >