Re: [musl] [BUG] sysconf implementing _SC_NPROCESSORS_(CONF|ONLN) incorrectly

[Norbert Lange <nolange79@gmail.com>]

How should  one deal with this?
I understand that the semantics are vague, but given that musl now
implements this
function, it will make detection and fallback hard (especially as musl
doesn't wants to be identified by the likes of macros).

As it is now, just using the affinity mask definitely cant be useful,
an application wanting that behavior should be patched to
use that function directly.
If musl would not define the _SC_NPROCESSORS_* macros (but still keep
the implementation),
this could be used for compile-time detection atleast. Enabling the
current implementation would be
just a matter of explicitly defining those macros.

Norbert

Am Di., 14. Apr. 2020 um 18:55 Uhr schrieb Florian Weimer <fw@deneb.enyo.de>:
>
> * Rich Felker:
>
> > On Tue, Apr 14, 2020 at 12:08:52PM +0200, Florian Weimer wrote:
> >> * Rich Felker:
> >>
> >> >> For glibc, we had to change our logic to artificially inflate the CPU
> >> >> to 2 if we cannot determine it, as the more conservative choice.
> >> >
> >> > Wait, you mean some software is abusing these interfaces to omit
> >> > memory barriers or something? *facepalm* *sigh*
> >>
> >> Yes, indeed.  glibc itself parses uname -v output for this purpose
> >> (something we should probably remove, too).
> >
> > I don't understand. Certainly it's not executing a child process at
> > runtime. Do you mean SYS_uname or are you talking about guessing
> > number of cpus for parallel build at make time or something?
>
> I meant the string that is printed by uname -v.  The internal
> implementation is of course different.