pset_bind(2) pset_bind(2)
NAME [Toc] [Back]
pset_bind - bind process or thread to a processor set
SYNOPSIS [Toc] [Back]
#include <sys/pset.h>
int
pset_bind(
psetid_t pset,
idtype_t idtype,
id_t id,
psetid_t *opset);
DESCRIPTION [Toc] [Back]
The pset_bind() function binds thread(s) or process(es) specified by
idtype and id to the processor set pset.
If idtype is P_PID, then id specifies the pid of the process to be
assigned, and the binding affects all threads of the process.
If idtype is P_LWPID, then id specifies the lwpid of the thread to be
assigned, and the binding affects only the specified thread. You
cannot specify a pthread id for pthreads in id, an lwpid is required.
See pthread_pset_bind_np in pthread_processor_bind_np(3T) for
information on binding pthreads to processor sets.
If idtype is P_UID, then id specifies the effective user id of all
processes to be assigned, and the binding affects all threads in these
processes. The operation is not a "success is all or none" type,
because it will rebind as many processes as possible without error.
If idtype is P_PGID, then id specifies the process group id of all
processes to be assigned, and the binding affects all threads in these
processes. The operation is not a "success is all or none" type,
because it will rebind as many processes as possible without error.
All processes in a process group need not have same access permissions
to target processor set.
If opset is not NULL, it contains the previous processor set binding
of the specified thread or process upon successful operation. However,
opset is ignored if idtype is P_UID or P_PGID.
All threads of a process need not be assigned to the same processor
set.
If id is P_MYID, then idtype identifies the target process(es) or
thread(s) to be assigned to pset. The P_PID identifies the calling
process, whereas P_LWPID identifies the calling thread. The P_UID
identifies all processes with the effective user id of the calling
process, and P_PGRP identifies all processes in the process group of
the calling process.
Hewlett-Packard Company - 1 - HP-UX 11i Version 2: August 2003
pset_bind(2) pset_bind(2)
If pset is PS_DEFAULT or PS_NONE, the system default processor set is
the target processor set.
If pset is PS_QUERY, the processor set binding is not changed, the
current processor set's processor set ID is returned in opset. If
idtype is P_UID or P_PGID, PS_QUERY request has no meaning. No special
access privileges are needed for PS_QUERY operation.
If pset is the same as the current processor set for the specified
process or thread, the operation is considered a PS_QUERY request.
The system daemon processes are not restricted to any user defined
processor sets. They may execute on any processor in the system
irrespective of the processor set configuration a user may have set
up. The processor set binding of system daemon processes may not be
changed. The PS_QUERY operation on system daemon processes will return
a special processor set ID of PS_KERNDAEMON to indicate they are
treated differently. NOTE: The system daemon processes are created in
the kernel for kernel activities, and not the user daemon processes
that execute in user space.
A superuser, a PRIV_PSET privilege user, or a user with EXEC
permission for the processor set pset may affect the binding change.
The pset_setattr() and pset_getattr() functions may be used to set and
query the processor set access permissions. See pset_getattr(2)).
If the thread or process being assigned to pset has binding to a
processor or a locality domain in its current processor set, the
binding is reassigned to a processor or locality domain in the new
processor set pset.
If pset is empty (no processors are assigned as yet), the behavior of
pset_bind() function depends on the value of PSET_ATTR_EMPTY
attribute. The default behavior on an attempt to bind a thread or a
process to an empty processor set is to fail the request.
The child process and its first thread created by a fork() or vfork()
function will inherit the processor set binding from the parent
process. The new threads in the multi-threaded process will inherit
their processor set binding from the creator thread.
EXAMPLE [Toc] [Back]
Migrate the current thread to another processor set new_pset, and
retrive its current processor set in old_pset.
#include <sys/pset.h>
int ret;
psetid_t new_pset, old_pset;
Hewlett-Packard Company - 2 - HP-UX 11i Version 2: August 2003
pset_bind(2) pset_bind(2)
/*
* Initialize new_pset first.
* Rebind the current thread to new_pset.
*/
ret = pset_bind( new_pset, P_LWPID, P_MYID, &old_pset);
if (ret < 0) {
perror("pset_bind");
exit(1);
}
RETURN VALUE [Toc] [Back]
pset_bind() returns zero on successful completion. Otherwise, -1 is
returned and errno is set to indicate the error.
ERRORS [Toc] [Back]
pset_bind fails if one or more of the following is true:
[EFAULT] The memory location pointed to by opset is not writable by
the user.
[EINVAL] pset is not valid.
[EINVAL] idtype or id is not valid.
[EINVAL] pset is empty and the current setting of processor set
attributes does not allow this operation on an empty
processor set.
[EINVAL] The memory location pointed to by opset is NULL and the
PS_QUERY operation is requested.
[ENOSYS] The processor set functionality is not supported by the
underlying HP-UX version.
[EPERM] User does not have necessary permissions to bind a thread
or a process to specified processor set.
[EPERM] The specified thread or process is a system daemon.
[ESRCH] The specified thread, process, user id, or process group
does not exist.
SEE ALSO [Toc] [Back]
psrset(1M), fork(2), pset_assign(2), pset_create(2), pset_ctl(2),
pset_destroy(2), pset_getattr(2), pset_setattr(2), vfork(2),
privgrp(4).
Hewlett-Packard Company - 3 - HP-UX 11i Version 2: August 2003 [ Back ] |
