On Tue, Nov 22, 2022 at 5:10 PM Ævar Arnfjörð Bjarmason
<avarab@xxxxxxxxx> wrote:
> On that platform, this also works:
> diff --git a/t/chainlint.pl b/t/chainlint.pl
> @@ -656,7 +656,7 @@ sub ncores {
> # 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*:/, <>)); } if -r '/proc/cpuinfo';
> + do { local @ARGV='/proc/cpuinfo'; return scalar(grep(/^(?:CPU\d+|processor\s*):/, <>)); } if -r '/proc/cpuinfo';
> # macOS & BSD
> return qx/sysctl -n hw.ncpu/ if $^O =~ /(?:^darwin$|bsd)/;
> return 1;
Thanks for digging into this. Your diagnosis matches the diagnosis in [1].
> Anyway, the "fix" here can also be:
>
> $jobs = ncores() if $jobs < 1;
> +$jobs = 1 if $jobs < 1;
>
> I.e. it's another case of bad /proc/cpuinfo parsing.
Yup, I suggested the same in [2] as a would-be-nice-to-have-eventually
patch, although only as a fallback, not as a proper fix for the
reported problem since a real fix (as you have above and as in [1])
would return the correct core count.
[1]: https://lore.kernel.org/git/CANYNYEHXU8ivgAOa8EO5e9kOcbu6XF7rj+9EcSrbDQE+Rvyw_Q@xxxxxxxxxxxxxx/
[2]: https://lore.kernel.org/git/CAPig+cQ6_7wf6C280Rqi7mcTCiQp-n5GiLWTPazfcUcGFeZi0g@xxxxxxxxxxxxxx/
