On 16 Oct 2015 17:06, Florian Weimer wrote: > The current situation, briefly stated, is this: glibc tries to guess the > kernel CPU set size and rejects attempts to specify an affinity mask > which is larger than that, but it does not work, and glibc and the > kernel still silently accept CPU affinity masks with invalid bits, > without returning an error. The glibc check does not provide any value > to applications, it just adds pointless complexity to the library. > Therefore, I want to remove it from glibc. checking the validty of the cpuset mask at the time of setting attributes seems fundamentally wrong to me. can't the cpuset change too between the check and the actual use ? say you have a controller that also manages the cpus, and it has pre-initialized the attributes, and then brings up the cpu on demand before spawning the thread. it wouldn't be possible to also pre-create all the attributes. patch makes sense to me > + abort (); why does the test call abort instead of exit ? abort writes to stderr. -mike
Attachment:
signature.asc
Description: Digital signature