Date: Wed, 15 Apr 2020 11:38:42 +0200 From: Norbert Lange <nolange79@...il.com> To: Florian Weimer <fw@...eb.enyo.de> Cc: Rich Felker <dalias@...c.org>, musl@...ts.openwall.com Subject: Re: [BUG] sysconf implementing _SC_NPROCESSORS_(CONF|ONLN) incorrectly 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@...eb.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.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.