On Mon, May 20, 2024 at 12:50 PM Eric Sunshine [off-list ref] wrote:

On Mon, May 20, 2024 at 12:16 PM Junio C Hamano [off-list ref] wrote:

quoted

        # 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).