Date: Wed, 16 Jan 2008 13:48:00 -0800 (PST)
From: "Roger A. Faulkner" <Roger.Faulkner at sun.com>
Subject: PSARC/2008/039 - POSIX scheduling interfaces
The proposed release binding is "minor release" (do I have that
right?) so it can be implemented in Solaris Nevada. I see no
need to do a back-port of this amount of change to Solaris 10.
This case seeks to make the POSIX standard scheduling interfaces,
implemented in libc, compatible with the Solaris scheduler class
interfaces, implemented by the priocntl() system call.
To this end, it is proposed to expand the list of POSIX-style
scheduling policies, defined in <sched.h>, from:
#define SCHED_OTHER 0
#define SCHED_FIFO 1 /* run to completion */
#define SCHED_RR 2 /* round-robin */
#define SCHED_SYS 3 /* sys scheduling class */
#define SCHED_IA 4 /* interactive class */
to:
#define SCHED_OTHER 0 /* traditional time-sharing scheduling class */
#define SCHED_FIFO 1 /* real-time class: run to completion */
#define SCHED_RR 2 /* real-time class: round-robin */
#define SCHED_SYS 3 /* system scheduling class */
#define SCHED_IA 4 /* interactive time-sharing class */
#define SCHED_FSS 5 /* fair-share scheduling class */
#define SCHED_FX 6 /* fixed-priority scheduling class */
To expunge the old libthread pseudo priority range, defined
privately inside of libc (formerly in libthread), altogether:
#define THREAD_MIN_PRIORITY 0 /* minimum scheduling pri */
#define THREAD_MAX_PRIORITY 127 /* max scheduling priority */
So far, so good...
To make the sched_*() and pthread_*() scheduling interfaces deal
with proper priority ranges, as defined by the priocntl(2)
interface, not the inverted nice value ranges as is done now for
SCHED_OTHER.
... but this change introduces an incompatibility, does it not?
To change the definition of the subcommand
PC_GETPRIRANGE
of the priocntl(2) interface and to invent a new
PC_DOPRIO
subcommand for the priocntl(2) interface, requiring
changes to the kernel scheduling class interface:
CL_GETCLPRI()
Each scheduling class must change its interface definition.
CL_DOPRIO()
Each scheduling class must inplement this new interface.
And finally to change the pthread default 'inheritsched' attribute
for pthread_create(3C) from:
PTHREAD_EXPLICIT_SCHED
to:
PTHREAD_INHERIT_SCHED
And don't these as well (excepting adding PD_DOPRIO)?
What stability level do the symbols you plan to remove have? What
stability levels do you propose for their replacements? What
will/might break should this project integrate as proposed? (What's
your best assessment of who or what might depend on the things the
project makes incompatible changes to?)
-- Glenn