On Mon, May 20, 2024 at 12:50 PM Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote:
> On Mon, May 20, 2024 at 12:16 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
> > # Windows
> > return $ENV{NUMBER_OF_PROCESSORS} if exists($ENV{NUMBER_OF_PROCESSORS});
> > # Linux / MSYS2 / Cygwin / WSL
> > - do { local @ARGV='/proc/cpuinfo'; return scalar(grep(/^processor[\s\d]*:/, <>)); } if -r '/proc/cpuinfo';
> > + do {
> > + local @ARGV='/proc/cpuinfo';
> > + my @num = grep(/^processor[\s\d]*:|^CPU[\d]*:/, <>);
> > +# print STDERR "FOUND <@num>\n";
> > + return 1 if (!@num);
> > + return scalar(@num);
> > + } if -r '/proc/cpuinfo';
> > # macOS & BSD
> > return qx/sysctl -n hw.ncpu/ if $^O =~ /(?:^darwin$|bsd)/;
> > return 1;
>
> I had a more all-inclusive change in mind. These number-of-cpu checks
> are in order from least to most costly but they are not necessarily
> mutually exclusive. As such, my thinking was that the logic would fall
> through to the next check if the preceding check produced zero or
> nonsense.
Hmph. Looking at this more closely, I guess I did make these more
mutually-exclusive than I had thought, so falling through to the next
check probably doesn't buy us much. In any case, for robustness, I
still think that each check needs to have a sensible fallback. An
alternative would be for the caller of ncores() to fallback to 1 if
ncores() returns 0 (or nonsense).
