Re: [PATCH] chainlint.pl: Extend regexp pattern for /proc/cpuinfo on Linux SPARC
- From
Eric Sunshine <sunshine@sunshineco.com>
- Date
- May 20, 2024, 17:07 UTC
- Message-ID
- <CAPig+cSGjE69N0TpB4ub7vY5fXHpDJ6j4-xet8G1zcgRo4OHHA@mail.gmail.com>
- In-Reply-To
- <CAPig+cQsc4AUJ7-0v=rS8VVK9JG1+_iSwa_gWUUigs=uwYq6Lw@mail.gmail.com>
On Mon, May 20, 2024 at 12:50 PM Eric Sunshine <sunshine@sunshineco.com> wrote:
Show 21 quoted lines
> On Mon, May 20, 2024 at 12:16 PM Junio C Hamano <gitster@pobox.com> 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).