Defect Report concerning: IEEE Std. 1003.1c-1995, ISO/IEC 9945-1:1990 AMD 2 - Threads
Clause: 13.3.3.2
PASC Interpretation Ref: pasc-1003.1c-19
Topic: sched_setparam


This is an unapproved interpretation of PASC 1003.1c-1995, ISO/IEC 9945-1:1990 AMD 2 - Threads.

Use of the information contained in this unapproved document is at your own risk.

Last update: 30 March,1998


								1003.1c-95  #19

 _____________________________________________________________________________

	Interpretation Number:	XXXX
	Topic:               sched_setparam
	Relevant Sections:   13.3.3.2

Interpretation Request: (Defect Report)
-----------------------

	Date: Tue, 16 Jul 1996 16:05:54 -0700
	From: "Scott J. Norton" <sjn@hpwssjn.cup.hp.com>

Section 13.3.1.2, page 114 D10, lines 30-36
Section 13.3.3.2, page 114 D10, lines 42-48

According to the new rules for scheduling, the sched_setparam() and
sched_setscheduler() are not useless in the presence of multithreaded
applications. The only effect these functions have is on the child
process (from fork()) of the target process. An implementation may cause
something to happen to the process scope threads, but thats all.

This provides a huge hole for system administrators. These functions have
a process parameter. This means they were intended so that a process
could control the policy and priority of another process. If that wasn't
the case, there wouldn't have been a pid as a parameter. Up until now
a system administrator could control a process if it was getting too much
or too little time on the system. Runaway processes with high priority
could be habndled.

With the new behavior, there is no way a sysadmin (or any process) can
control the behavior of a multithreaded process. If some event happens
requiring a change in the policy/priority of the MT process, only the
process itself can do it. 

The worst part is that if one thread in the process goes out of control
while high prio SCHED_FIFO, no one can control it. A sysadmin cannot
do anything to lower that thread's priority (thread IDs are not guaranteed
to be known outside of the system).

Is this the actual intended behavior?


Interpretation response
------------------------

This is a duplicate.  See PASC P1003.1c Interpretation #3, part 7

Rationale
-------------
None.
Forwarded to Interpretations group: July 17th 1996
Finalised: Sep 4 1996