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: "Carlos O'Donell" <carlos at redhat dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Tue, 23 Jul 2013 14:09:53 -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> <20130723023520 dot GG4977 at spoyarek dot pnq dot redhat dot com>
On 07/22/2013 10:35 PM, Siddhesh Poyarekar wrote:
> On Mon, Jul 22, 2013 at 06:34:32PM -0400, Carlos O'Donell wrote:
>> The reality of the situation is that the linux kernel as an abstraction
>> presents the following:
>>
>> (a) The number of online cpus.
>> - Changes dynamically.
>> - Not constant for the life of the process, but pretty constant.
>
> Values returned by sysconf are required[1] to be constant for the
> lifetime of a process.
>
> The value returned shall not be more restrictive than the
> corresponding value described to the application when it was
> compiled with the implementation's <limits.h> or <unistd.h>. The
> value shall not change during the lifetime of the calling process,
> [XSI] [Option Start] except that sysconf(_SC_OPEN_MAX) may return
> different values before and after a call to setrlimit() which
> changes the RLIMIT_NOFILE soft limit.
>
> although I guess there is merit in considering _SC_NPROCESSORS_* for
> an exception similar to OPEN_MAX. That fact needs to be documented
> though.
Sorry, just to clarify, are you saying that OPEN_MAX needs a similar
exception or that it already has one?
I don't see anything in the glibc manual, linux kernel man pages, or
POSIX about _SC_OPEN_MAX being non-constant.
I know that sysconf values are expected to be constant for the lifetime
of the process, but this is just not true for _SC_NPROCESSORS_ONLN.
Currently in glibc we do not guarantee that _SC_NPROCESSORS_ONLN is
constant.
It would be a shame to throw away sysconf and write an almost identical
API to handle non-constant values.
I would rather say:
(a) These value are constant as required by POSIX: <list of them>
(b) These values are not-constant: <list of them>
Then change the sysconf wording to say "the values returned may or may
not be constant depending on the value. See the definition of the value
for more details."
Cheers,
Carlos.