Date: Wed, 15 Apr 2020 11:50:36 +0200 From: Florian Weimer <fw@...eb.enyo.de> To: Norbert Lange <nolange79@...il.com> Cc: musl@...ts.openwall.com, Rich Felker <dalias@...c.org> Subject: Re: [BUG] sysconf implementing _SC_NPROCESSORS_(CONF|ONLN) incorrectly * Norbert Lange: > 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. _SC_NPROCESSORS_* as implemented in glibc is bad because those values are not adjusted by cgroups, so it can grossly overestimate available resources. The cgroups interfaces themselves are not stable and very complicated. I don't think it's a good idea to target them, especially not from code that is expected to be linked statically into applications. Given that, I'm not sure that glibc's way is a significant improvement. musl should perhaps be changed to cope more gracefully with a sched_getaffinity failure, though (by not reporting a UP environment by accident).
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.