On Tuesday 23 April 2002 05:32 am, Michael Gonzalez wrote:
> @ page 1228 line 38226 section sched_get_priority_max() objection
>
> Problem:
>
> The sched_get_priority_max() and sched_get_priority_min() functions
> are required for the application to determine the range of priorities
> that are valid for a given scheduling policy, such as SCHED_FIFO. If
> these functions are not present, it is not possible for an application
> to determine which are the valid priorities (for example, an
> implementation might legally use a range between 337-369 for some
> obscure reason).
>
> The problem is that these functions are not required under the thread
> priority scheduling option (TPS code); they are only required under
> the process priority scheduling option. Therefore, it is not possible
> to write a strictly conforming application that sets its priority for
> an implementation supporting thread priority scheduling but not
> process priority scheduling (as mandated for example in the POSIX.13
> small realtime profiles).
>
> This problem was also present in POSIX.1-1996, but was not discovered
> until the first implementations of the POSIX.13 minimal realtime
> system profile.
>
> Action:
>
> Change the PS code in the synopsis of these two functions into
> PS|TPS (process priority scheduling or thread priority scheduling)
>
> -------------
>
> @ page 1231 line 38343 section sched_rr_get_interval() objection
>
> Problem:
>
> The sched_rr_get_interval() function is required for the application
> to determine the interval for the round robin scheduler. If this
> function is not present, it is not possible for an application to
> determine which is this interval.
>
> The problem is that this function is not required under the thread
> priority scheduling option (TPS code); it is only required under the
> process priority scheduling option. Therefore, it is not possible to
> write a strictly conforming application that uses the round robin
> interval, for an implementation supporting thread priority scheduling
> but not process priority scheduling (as mandated for example in the
> POSIX.13 small realtime profiles).
>
> This problem was also present in POSIX.1-1996, but was not discovered
> until the first implementations of the POSIX.13 minimal realtime
> system profile.
>
> Action:
>
> Change the PS code in the synopsis of this function into PS|TPS
> (process priority scheduling or thread priority scheduling)
While I have always agreed with the problem statement and the suggested
resolution, I'll dutifully point out that the statement that it "was not
discovered until the first implementations of the POSIX.13 minimal realtime
system profile" is incorrect. I pointed out the loophole with the priority
min/max functions (though I missed the interval) in PASC 1003.1c
interpretation request #29, in August 1996. The official resolution was "The
interpretations committee believes that not requiring the definition of these
functions may make the _POSIX_THREAD_PRIORITY_SCHEDULING option less useful
and was not the intention of the working and balloting groups. This is being
referred to the sponsor for consideration."
I'm afraid this is one "we" missed during the SUS3 (not to mention SUS2)
review. I even made an effort at one point to convert old interpretations
into Aardvarks, and apparently I missed one of my own. Sheesh! Sorry. Six
years is probably long enough: can we get it into the corrigenda?
/------------------[ yyyyyyyyyyyyyy@xxxxxxxxxx ]------------------\
| Compaq Computer Corporation POSIX Thread Architect |
| My book: http://www.awl.com/cseng/titles/0-201-63392-2/ |
\-----[ http://home.earthlink.net/~anneart/family/dave.html ]-----/
|