PSET_BIND(2) | System Calls | PSET_BIND(2) |
#include <sys/pset.h> int pset_bind(psetid_t pset, idtype_t idtype, id_t id, psetid_t *opset);
If idtype is P_PID, the binding affects all LWPs of the process with process ID (PID) id.
If idtype is P_LWPID, the binding affects the LWP of the current process with LWP ID id.
If idtype is P_TASKID, the binding affects all LWPs of all processes with task ID id.
If idtype is P_PROJID, the binding affects all LWPs of all processes with project ID id.
If idtype is P_ZONEID, the binding affects all LWPs of all processes with zone ID id.
If idtype is P_CTID, the binding affects all LWPs of all processes with process contract ID id.
If id is P_MYID, the specified LWP, process, task, process, zone, or process contract is the current one.
If pset is PS_NONE, the processor set bindings of the specified LWPs are cleared.
If pset is PS_QUERY, the processor set bindings are not changed.
If pset is PS_MYID, the specified LWPs are bound to the same processor set as the caller. If the caller is not bound to a processor set, the processor set bindings are cleared.
The {PRIV_SYS_RES_CONFIG} privilege must be asserted in the effective set of the calling process or pset must be PS_QUERY.
LWPs that have been bound to a processor with processor_bind(2) may also be bound to a processor set if the processor is part of the processor set. If this occurs, the binding to the processor remains in effect. If the processor binding is later removed, the processor set binding becomes effective.
Processor set bindings are inherited across fork(2) and exec(2).
EBUSY
EFAULT
EINVAL
ENOTSUP
Binding a system process to a processor set is not supported.
EPERM
ESRCH
ATTRIBUTE TYPE | ATTRIBUTE VALUE |
Interface Stability | Committed |
MT-Level | Async-Signal-Safe |
March 13, 2009 | OmniOS |