This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: What *is* the API for sched_getaffinity? Should sched_getaffinity always succeed when using cpu_set_t?
- From: KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Mon, 22 Jul 2013 23:52:14 -0400
- Subject: Re: What *is* the API for sched_getaffinity? Should sched_getaffinity always succeed when using cpu_set_t?
- References: <51E42BFE dot 7000301 at redhat dot com> <51E4A0BB dot 2070802 at gmail dot com> <51E4A123 dot 9070001 at gmail dot com> <51E6F3ED dot 8000502 at redhat dot com> <51E6F956 dot 5050902 at gmail dot com> <51E714DE dot 6060802 at redhat dot com> <CAHGf_=oZW3kNA3V-9u+BZNs3tL3JKCsO2a0Q6f0iJzo=N4Wb8w at mail dot gmail dot com> <51E7B205 dot 3060905 at redhat dot com> <20130722214335 dot D9AFF2C06F at topped-with-meat dot com> <51EDB378 dot 8070301 at redhat dot com> <20130722224553 dot 933BA2C070 at topped-with-meat dot com> <51EDB993 dot 9000204 at redhat dot com>
> * Used to create a minimally sized structure to track
> per-logical-CPU data.
> - As it is implemented _SC_NPROCESSORS_CONF is a minimal
> value. Fixing it to match your expected semantics e.g
> making it the number of possible CPUs, is going
> to make this value potentially much larger.
Hmm.
This doesn't cross my mind. I think this case should use (c) because otherwise
your application may crash when cpu hotplug occur.
Practically, we have no way to know cpu hot adding _synchronously_ and
there is several
race window if you are polling to change ._SC_NPROCESSORS_CONF value.
Actually, in kernel possible cpus structure was mainly created to
effectively represent
per-cpu data.