Use of the information contained in this unapproved document is at your own risk
.Last update: 30 March,1998
1003.1c-95 #17 _____________________________________________________________________________ Interpretation Number: 17 Topic: pthread_attr_setschedparam Relevant Clauses: 13.5.1.2 Interpretation Request: (Defect Report) ----------------------- Date: Tue, 16 Jul 1996 16:06:09 -0700 From: "Scott J. Norton" <sjn@hpwssjn.cup.hp.com> 3) Section: 13.5.1.2, pthread_attr_setschedparam() page 122 pthread_attr_setschedpolicy() page 122 These functions do not provide for an EPERM error condition. All other scheduling functions have an EPERM to signify that the user doesn't have permission to set these particular scheduling attributes. Similarly, pthread_create() also does not contain an EPERM. This behavior requires implementations to let anyone use the SCHED_FIFO/SCHED_RR policies and priorities, even though all other functions trying to use them may return EPERM. What is the correct behavior? Are there supposed to be EPERM error returns for these functions? Should there be an error of EPERM for pthread_create() instead? Should all three functions have an EPERM error return? Interpretation Response ----------------------- The standard is clear that setting the scheduling policy or priority values in the scheduling attribute object does not actually change the value for any threads. It is only when the attribute object is used in a pthread_create that the parameters are used and it is at that time that the parameters shall be consistent. The scheduling policy and priorities of an existing thread may be changed using the pthread_setschedparm function which requires both a policy and a priority. The standard is silent on what permissions, if any, an application must have to perform a pthread_create. Conforming implementations are free to not restrict access or to restrict access and return EPERM if detected. Conforming applications must handle this case. Rationale --------- It is not possible to detect or report EPERM error conditions when modifying the scheduling parameter attributes. The intent was that attributes objects may be thought of as user data structures, and the various set and get functions might be nothing more than macros that assign (or read) data to or from members of that structure. Forwarded to Interpretations group: July 17th 1996 Finalised: 14 April 1997