Date: Thu, 17 Jan 2008 12:25:22 -0800 (PST)
From: "Roger A. Faulkner" <Roger.Faulkner at sun.com>
Subject: Re: 2008/039 [POSIX scheduling interfaces]
> Date: Thu, 17 Jan 2008 10:25:27 -0800 (PST)
> From: Glenn Skinner <glenn.skinner at sun.com>
> Subject: Re: 2008/039 [POSIX scheduling interfaces]
> [various questions concerning stability and compatibility]
...
Yes, but it rectifies a standards violation. The standards
interfaces require priorities, low to high, to reflect real
scheduling priorities, low to high.
The old behavior of returning nice values (inverted at that) was
just a badly mistaken bug.
...
Well, my understanding of the scheduler class interfaces in the
kernel is that it is all uncommitted, unstable, whatever. Not
even as high as 'evolving'.
The priocntl() interfaces are a bit higher, but the PC_GETPRIRANGE
subcommand in particular is consolidation private:
From <sys/priocntl.h>:
#define PC_GETPRIRANGE 5 /* Get global priority range for a class */
/* posix.4 scheduling, not for general use
*/
and my addition to this file should also be consolidation private:
#define PC_DOPRIO 11 /* Set or get priority, not for general use
*/
I'm not deleting any visible symbols. The THREAD_MIN_PRIORITY and
THREAD_MAX_PRIORITY were never visible as themselves. Only
thr_setprio() and thr_getprio() ever documented their ranges.
What will break? It's hard to say. Something that actually
believed the old stuff worked, I guess. (It never did.)
Certainly, third-party scheduling classes will break.
But I couldn't find any using Google.
Ok, that's what I wanted to know and I'm satisfied with the answers.
Thanks!
-- Glenn
