Expose sched.h functions

[neologix_free.fr]

Here's a review.

> > Why didn't you use something like:
> >
> > $ taskset <cpu mask> python myscript.py
>
> Because I didn't want to type that every time I ran the
> script.

Something along those lines:
os.system('taskset -p <mask> %d' % os.getpid())

would have done the trick ;-)

http://bugs.python.org/review/12655/diff/3115/9656
File Doc/library/os.rst (right):

http://bugs.python.org/review/12655/diff/3115/9656#newcode2791
Doc/library/os.rst:2791: .. class:: sched_param(sched_prioirity)
typo: priority

http://bugs.python.org/review/12655/diff/3115/9656#newcode2855
Doc/library/os.rst:2855: :class:`cpu_set` represents a set of CPUs on which a
process runs. *ncpus* is
It's not really a "set of CPUs on which a process runs", but rather "set of CPUs
on which a process is eligible to run".

http://bugs.python.org/review/12655/diff/3115/9656#newcode2894
Doc/library/os.rst:2894: 
Thos functions accept too a PID of 0 to denote the calling process (to be
consistent with the other funtions).

http://bugs.python.org/review/12655/diff/3115/9657
File Lib/test/test_posix.py (right):

http://bugs.python.org/review/12655/diff/3115/9657#newcode858
Lib/test/test_posix.py:858: init = posix.sched_getscheduler(1)
Hm, I don't know if you're guaranteed to be able to retrieve the scheduling
policy of processes running with UID 0: this might fail with EPERM on a hardened
kernel.

http://bugs.python.org/review/12655/diff/3115/9657#newcode880
Lib/test/test_posix.py:880: interval = posix.sched_rr_get_interval(0)
Is it guaranteed to succeed even if the current process doesn't run with
SCHED_FIFO?

http://bugs.python.org/review/12655/diff/3115/9658
File Modules/posixmodule.c (right):

http://bugs.python.org/review/12655/diff/3115/9658#newcode4683
Modules/posixmodule.c:4683: sched_param class.");
A *pid* of 0 is allowed here too.

http://bugs.python.org/review/12655/diff/3115/9658#newcode4709
Modules/posixmodule.c:4709: "sched_setparam(pid, param)\n\n\
Same here.

http://bugs.python.org/review/12655/diff/3115/9658#newcode4785
Modules/posixmodule.c:4785: return NULL;
The check against NULL should be before dereferencing it.

[Benjamin Peterson]

Thanks for the review.

http://bugs.python.org/review/12655/diff/3115/9657
File Lib/test/test_posix.py (right):

http://bugs.python.org/review/12655/diff/3115/9657#newcode880
Lib/test/test_posix.py:880: interval = posix.sched_rr_get_interval(0)
On 2011/07/31 00:37:27, Charles-François Natali wrote:
> Is it guaranteed to succeed even if the current process doesn't run with
> SCHED_FIFO?

Yes.

[storchaka]

http://bugs.python.org/review/12655/diff/5651/Modules/posixmodule.c
File Modules/posixmodule.c (right):

http://bugs.python.org/review/12655/diff/5651/Modules/posixmodule.c#newcode5744
Modules/posixmodule.c:5744: ncpus = 16;
"Since CPU sets are bitsets allocated in units of long words, the actual number
of CPUs in a dynamically allocated CPU set will be rounded up to the next
multiple of sizeof(unsigned long)."

    ncpus = sizeof(unsigned long) * CHAR_BIT;

http://bugs.python.org/review/12655/diff/5651/Modules/posixmodule.c#newcode5770
Modules/posixmodule.c:5770: if (cpu > INT_MAX - 1) {
"The constant CPU_SETSIZE (currently 1024) specifies a value one greater than
the maximum CPU number that can be stored in cpu_set_t."

    if (cpu >= CPU_SETSIZE) {

http://bugs.python.org/review/12655/diff/5651/Modules/posixmodule.c#newcode5776
Modules/posixmodule.c:5776: int newncpus = ncpus;
I don't see usage of old ncpus in this block. Is newncpus variable unnecessary?

http://bugs.python.org/review/12655/diff/5651/Modules/posixmodule.c#newcode5780
Modules/posixmodule.c:5780: if (newncpus > INT_MAX / 2)
    if (newncpus > CPU_SETSIZE / 2)
        newncpus = CPU_SETSIZE;
    else
        newncpus *= 2;

http://bugs.python.org/review/12655/diff/5651/Modules/posixmodule.c#newcode5834
Modules/posixmodule.c:5834: ncpus = 16;
    ncpus = sizeof(unsigned long) * CHAR_BIT;

http://bugs.python.org/review/12655/diff/5651/Modules/posixmodule.c#newcode5845
Modules/posixmodule.c:5845: if (ncpus > INT_MAX / 2) {
    if (newncpus >= CPU_SETSIZE) {
        PyErr_SetString(PyExc_OverflowError, "could not allocate "
                        "a large enough CPU set");
        return NULL;
    }
    if (ncpus > CPU_SETSIZE / 2)
        ncpus = CPU_SETSIZE;
    else
        ncpus *= 2;

http://bugs.python.org/review/12655/diff/5651/Modules/posixmodule.c#newcode5873
Modules/posixmodule.c:5873: if (mask)
mask always is not NULL.

[AntoinePitrou]

http://bugs.python.org/review/12655/diff/5651/Modules/posixmodule.c
File Modules/posixmodule.c (right):

http://bugs.python.org/review/12655/diff/5651/Modules/posixmodule.c#newcode5744
Modules/posixmodule.c:5744: ncpus = 16;
On 2012/08/04 15:09:05, storchaka wrote:
> "Since CPU sets are bitsets allocated in units of long words, the actual
number
> of CPUs in a dynamically allocated CPU set will be rounded up to the next
> multiple of sizeof(unsigned long)."
> 
>     ncpus = sizeof(unsigned long) * CHAR_BIT;

Well, starting at 16 is a heuristic. I don't really see a point in making it
more complicated.

http://bugs.python.org/review/12655/diff/5651/Modules/posixmodule.c#newcode5770
Modules/posixmodule.c:5770: if (cpu > INT_MAX - 1) {
On 2012/08/04 15:09:05, storchaka wrote:
> "The constant CPU_SETSIZE (currently 1024) specifies a value one greater than
> the maximum CPU number that can be stored in cpu_set_t."
> 
>     if (cpu >= CPU_SETSIZE) {

You can store more than CPU_SETSIZE if you allocate the cpu_set_t dynamically:

“Because some applications may require the ability to dynamically size CPU sets
(e.g., to allocate sets larger than that defined by the standard cpu_set_t data
type), glibc nowadays provides a set of macros
to support this.”

http://bugs.python.org/review/12655/diff/5651/Modules/posixmodule.c#newcode5776
Modules/posixmodule.c:5776: int newncpus = ncpus;
On 2012/08/04 15:09:05, storchaka wrote:
> I don't see usage of old ncpus in this block. Is newncpus variable
unnecessary?

I find it more readable.

http://bugs.python.org/review/12655/diff/5651/Modules/posixmodule.c#newcode5780
Modules/posixmodule.c:5780: if (newncpus > INT_MAX / 2)
On 2012/08/04 15:09:05, storchaka wrote:
>     if (newncpus > CPU_SETSIZE / 2)
>         newncpus = CPU_SETSIZE;
>     else
>         newncpus *= 2;

No, see above.

http://bugs.python.org/review/12655/diff/5651/Modules/posixmodule.c#newcode5845
Modules/posixmodule.c:5845: if (ncpus > INT_MAX / 2) {
On 2012/08/04 15:09:05, storchaka wrote:
>     if (newncpus >= CPU_SETSIZE) {
>         PyErr_SetString(PyExc_OverflowError, "could not allocate "
>                         "a large enough CPU set");
>         return NULL;
>     }
>     if (ncpus > CPU_SETSIZE / 2)
>         ncpus = CPU_SETSIZE;
>     else
>         ncpus *= 2;

Again, see above about dynamically-allocated cpu_set_t's.

http://bugs.python.org/review/12655/diff/5651/Modules/posixmodule.c#newcode5873
Modules/posixmodule.c:5873: if (mask)
On 2012/08/04 15:09:05, storchaka wrote:
> mask always is not NULL.

True.

[storchaka]

http://bugs.python.org/review/12655/diff/5651/Modules/posixmodule.c
File Modules/posixmodule.c (right):

http://bugs.python.org/review/12655/diff/5651/Modules/posixmodule.c#newcode5744
Modules/posixmodule.c:5744: ncpus = 16;
On 2012/08/04 15:14:15, AntoinePitrou wrote:
> On 2012/08/04 15:09:05, storchaka wrote:
> > "Since CPU sets are bitsets allocated in units of long words, the actual
> number
> > of CPUs in a dynamically allocated CPU set will be rounded up to the next
> > multiple of sizeof(unsigned long)."
> > 
> >     ncpus = sizeof(unsigned long) * CHAR_BIT;
> 
> Well, starting at 16 is a heuristic. I don't really see a point in making it
> more complicated.

There is no sense to start less than sizeof(unsigned long) * CHAR_BIT. For 16
and 32 cpus same size will be allocated.

http://bugs.python.org/review/12655/diff/5651/Modules/posixmodule.c#newcode5770
Modules/posixmodule.c:5770: if (cpu > INT_MAX - 1) {
On 2012/08/04 15:14:15, AntoinePitrou wrote:
> On 2012/08/04 15:09:05, storchaka wrote:
> > "The constant CPU_SETSIZE (currently 1024) specifies a value one greater
than
> > the maximum CPU number that can be stored in cpu_set_t."
> > 
> >     if (cpu >= CPU_SETSIZE) {
> 
> You can store more than CPU_SETSIZE if you allocate the cpu_set_t
dynamically:
> 
> “Because some applications may require the ability to dynamically size CPU
sets
> (e.g., to allocate sets larger than that defined by the standard cpu_set_t
data
> type), glibc nowadays provides a set of macros
> to support this.”

You're right. I'm wrong.