United States-English |
|
|
HP-UX Reference > Rrtprio(2)HP-UX 11i Version 3: February 2007 |
|
NAMErtprio — change or read real-time priority DESCRIPTIONThe rtprio() system call sets or reads the real-time priority of a process. If pid is zero, it specifies the calling process; otherwise, it specifies the process ID of a process. If the process pid contains more than one thread or a lightweight process (that is, the process is multi-threaded), this function shall only change the process scheduling policy and priority. Individual threads or lightweight processes in the target process shall not have their scheduling policies and priorities modified. Note that if the target process is multi-threaded, this process scheduling policy and priority change will only affect a child process that is created later and inherits its parent's scheduling policy and priority. The priority returned is the value of the target's old priority, though individual threads or lightweight processes may have a different value if some other interface is used to change an individual thread or lightweight processes priority. When setting the real-time priority of another process, the real or effective user ID of the calling process must match the real or saved user ID of the process to be modified, or the effective user ID of the calling process must be that of a user having appropriate privileges. The calling process must also be a member of a privilege group allowing rtprio() (see getprivgrp(2)) or the effective user ID of the calling process must be a user having appropriate privileges. Simply reading real-time priorities requires no special privilege. Real-time scheduling policies differ from normal timesharing policies in that the real-time priority is used to absolutely order all real-time processes. This priority is not degraded over time. All real-time processes are of higher priority than normal user and system processes, although some system processes may run at real-time priorities. If there are several eligible processes at the same priority level, they are run in a round robin fashion as long as no process with a higher priority intervenes. A real-time process receives CPU service until it either voluntarily gives up the CPU or is preempted by a process of equal or higher priority. Interrupts can also preempt a real-time process. Valid real-time priorities run from zero to 127. Zero is the highest (most important) priority. This real-time priority is inherited across forks (see fork(2)) and execs (see exec(2)). prio can have the following values:
Security RestrictionsSome or all of the actions associated with this system call are subject to compartmental restrictions. See compartments(5) for more information about compartmentalization on systems that support that feature. Compartmental restrictions can be overridden if the process possesses the COMMALLOWED privilege (PRIV_COMMALLOWED). Processes owned by the superuser may not have this privilege. Processes owned by any user may have this privilege, depending on system configuration. Some or all of the actions associated with this system call require one or more privileges. Processes owned by the superuser have many, though not all, privileges. Processes owned by other users may have privilege(s), depending on system configuration. See privileges(5) for more information about privileged access on systems that support fine-grained privileges. RETURN VALUErtprio() returns the following values:
ERRORSIf rtprio() fails, errno is set to one of the following values:
EXAMPLESThe following call to rtprio() sets the calling process to a real-time priority of 90: rtprio(0, 90); WARNINGSNormally, compute-bound programs should not be run at real-time priorities, because all timesharing work on the CPU would come to a complete halt. DEPENDENCIESBecause processes executing at real-time priorities get scheduling preference over a system process executing at a lower priority, unexpected system behavior can occur after a power failure on systems that support power-fail recovery. For example, when init (see init(1M)) receives the powerfail signal SIGPWR, it normally reloads programmable hardware such as terminal multiplexers. If a higher-priority real-time process is eligible to run after the power failure, the running of init is delayed. This condition temporarily prevents terminal input to any process, including real-time shells of higher priority than the eligible real-time process. To avoid this situation, a real-time process should catch SIGPWR and suspend itself until init has finished its powerfail processing. |
Printable version | ||
|