Re: git: 48bfd3597654 - main - Add nproc(1)

As far as I can tell, it is unlikely that any choice is
going to be universal for a sysconf(...) context.
Part of that is that POSIX does not have the _SC_* names
involved for "nproc". But there is a broader issue as well:

POSIX.1-2017, for example, says of long sysconf(int name):
(I ignore here material about returing -1/errno handling.)

QUOTE
The value shall not change during the lifetime of the calling process
END QUOTE

A XSI note adds that

QUOTE
except that sysconf(_SC_OPEN_MAX) may return different values before and after a call to setrlimit() which changes the RLIMIT_NOFILE soft limit
END QUOTE

(So, one XSI exception noted.)

The rationale section has some more related words:

QUOTE
This runtime facility is not meant to provide ever-changing values that applications have to check multiple times. The values are seen as changing no more frequently than once per system initialization, such as by a system administrator or operator with an automatic configuration program. This volume of POSIX.1-2017 specifies that they shall not change within the lifetime of the process.
END QUOTE

It looks to me like, in this "nproc" area, sysconf(name)
is being abused related to its POSIX intended range of
functionality. Not a good context for getting stable
definitions across systems/libraries or over time.

That said, ignoring cpuset/taskset would be appropriate
to the POSIX.1-2017 wording for anything sysconf(name)
is to return and using cpuset/taskset looks to be
inappropriate.

(I did not review the POSIX history prior to the 2017
context.)

If some forms of sysconf(name) use are to not fit with
the POSIX property indicated, it likely needs to be well
documented for that and whatever other criteria were used
instead also needs to be well documented for the names
that do not get the property.

===
Mark Millard
marklmi at yahoo.com