Glenn Skinner wrote: > 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 > After raf's posting, I want to check and clarify the commitments, which will take me a day or so. I agree that what raf is doing is the right thing (I remember some of these issues), so at most this will result in a few more words in raf's proposal.
- jek3
