Re: What *is* the API for sched_getaffinity? Should sched_getaffinity always succeed when using cpu_set_t?

["Carlos O'Donell" <carlos at 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.