process_management(3K) SDK R4.11 process_management(3K)
NAME
process_management: pm_get_my_pid, pm_get_my_pgid,
hdl_get_my_process_handle, pc_is_interrupted, pc_is_terminated,
sig_kernel_send_to_process_group_id, sig_kernel_send_to_process -
manage processes and signals
SYNOPSIS
#include "/usr/src/uts/aviion/ii/i_pm.h"
#include "/usr/src/uts/aviion/ii/i_pc.h"
#include "/usr/src/uts/aviion/ii/i_sig.h"
#include "/usr/src/uts/aviion/ii/i_hdl.h"
gid_t pm_get_my_pgid (void)
pid_t pm_get_my_pid (void)
hdl_process_handle_type hdl_get_my_process_handle (void)
boolean_type pc_is_interrupted (vp_event_ptr_type event_ptr)
boolean_type pc_is_terminated (vp_event_ptr_type event_ptr)
void sig_kernel_send_to_process_group_id (pid_t
target_group, sig_signal_number_type
signal_number)
void sig_kernel_send_to_process
(hdl_process_handle_type target_handle,
sig_signal_number_type signal_number)
where:
event_ptr The address of a LWP's interrupt event.
handle The subject process' handle.
process_group The process group ID of the target process group.
process_id The process ID of the target process.
signal_number The number of the signal being sent.
DESCRIPTION
The following routines are described in this man page:
pm_get_my_pid Return process ID of the calling LWP's
process
pm_get_my_pgid Return calling LWP's process group
hdl_get_my_process_handle Return the calling LWP's process handle
pc_is_interrupted Check for any unblocked signal that
needs to be handled during a system call
pc_is_terminated Check for unblocked termination signals
during a system call
sig_kernel_send_to_process_group_id
Send a signal to a process group
sig_kernel_send_to_process Send signal to process identified by PID
Overview to Using Process Signal Management Routines
The DG/UX kernel allows you to send a signal to either a particular
process or to a group of processes. You can send signals selectively
based on the target process': 1) process handle; or 2) process group
(PGID). The routines you use are: sig_kernel_send_to_process, and
sig_kernel_send_to_process_group_id. In the DG/UX kernel, it is more
efficient and reliable to refer to processes by their process handle
than by their PID. Hence, signaling by sig_kernel_send_to_process is
the preferred method.
Typically you will be sending signals to your own process or other
processes in your process group, and you will need the appropriate
process identifier. You can determine you own PID and PGID by call
ing pm_get_my_pid or pm_get_my_pgid, respectively. You can determine
your own process handle by calling hdl_get_my_process_handle.
You must query the kernel to find out if you have a signal pending.
You query for any pending signals using the pc_is_interrupted and
pc_is_terminated routines.
The kernel identifies two classes of signals: normal ones that the
calling LWP can handle; and terminal ones that will cause the calling
LWP's process to terminate (with or without a core dump). You call
pc_is_interrupted to query about both normal and terminate signals.
You call pc_is_terminated to query about terminate signals only.
The DG/UX kernel implements signals as software interrupts. The
query routine (for example, pc_is_interrupted) returns TRUE if the
LWP has an signal pending that needs to be handled. If a signal is
not present, the routine returns FALSE and returns an interruption
event to await. You can use this event to suspend and wait for a
signal to interrupt the LWP. To do so you add the event to the list
of events to be awaited and call vp_await_ec. If the interruption
event is satisfied, you should verify that a signal has occurred by
calling the query routine again.
Note that pc_is_interrupted may internally suspend the calling LWP
for an arbitrary amount of time and should only be used when an in
definite wait is possible. For example, if a process that is being
debugged receives a signal, it will communicate with its debugger
during pc_is_interrupted (see ptrace(2)). Because of this,
pc_is_interrupted may pend indefinitely waiting for a debugger to
continue the calling LWP's process. Because it may pend indefinite
ly, you should avoid holding locks when calling pc_is_interrupted.
pc_is_terminated is designed for use within the kernel when a poten
tially long, but nevertheless finite length operation is started.
For example, a space operation on a tape drive or an I/O request to
an NFS server are such potentially long operations. In either case
the operation will eventually finish (possibly due to a time-out),
but the user may like the option to terminate the operation mid-
stream by sending the process a signal. pc_is_terminated does not
communicate with any debugger process and does not flag non-terminal
signals. Because it only informs the caller of terminal signals, you
can safely call it while holding a lock.
Constants and Data Structures
This subsection describes constants and data structures defined in
the include files cited in the SYNOPSIS section and used by the rou
tines documented in this man page.
Try to avoid dependencies on the specifics of these structures, such
as size or location of fields, because these specifics may change in
later releases of the software. You can verify exact variable defi
nitions in the appropriate include file. The best way to avoid such
dependencies is to use kernel-supplied routines to manipulate these
structures.
pm_get_my_pgid
This routine returns the process group of the calling LWP.
pm_get_my_pid
This routine returns the process id of the calling LWP.
hdl_get_my_process_handle
This routine returns the process handle of the calling LWP.
pc_is_interrupted
This routine returns if the LWP is interrupted by a signal. It
should be used whenever a system call will pend the calling LWP until
some external event occurs (that is, pend for an arbitrary amount of
time). Processing includes the following:
· Interrupting the system call.
· Terminating the process (with or without a core dump).
· Stopping the process for an arbitrary amount of time.
Only the last of these actions is contained entirely within the
pc_is_interrupted routine. The first two actions are performed in
cooperation with the caller.
Typically, you will use the following code fragment:
if (pc_is_interrupted(&events[LWP_INTERRUPT]))
{
Arrange to return EINTR to the user. Exit with error EINTR.
}
vp_await_ec(events, N, &index);
Act on the event that was satisfied.
If only the LWP_INTERRUPT was satisfied, loop back to
pc_is_interrupted().
In the code shown above, the relevant events are those in the
events[] array in the first line. If the calling LWP is interrupted
pc_is_interrupted will return TRUE and the system call will return an
error and will set errno to EINTR. Otherwise, pc_is_interrupted will
return FALSE and will return in events[LWP_INTERRUPT] the event to
await for the LWP to be interrupted. The system call pends until the
calling LWP is interrupted or one of the relevant events has hap
pened. If only the LWP_INTERRUPT event was satisfied, then loop back
to pc_is_interrupted to verify the LWP was interrupted.
pc_is_terminated
This routine checks for termination signals during a system call.
This routine determines whether the calling LWP has any signals that
will cause process termination.
This call is designed for use within the kernel when a potentially
long but nevertheless finite operation is started. For example, a
spacing operation on a tape drive or an I/O request to an NFS server
is essentially indefinite. In both of these cases, the operation is
guaranteed to eventually finish, perhaps due to a timeout; but the
end user may like the option of terminating the operation mid-stream
by sending the process a signal.
sig_kernel_send_to_process_group_id
This routine sends a signal to a process group.
The routine sends the signal signal_number to the processes whose
process group ID is process_group. The signal is sent only to pro
cesses that are not system processes and to which the calling LWP has
permission to send a signal.
sig_kernel_send_to_process
If the subject process exists, this routine sends the process a sig
nal. If the subject process does not exist, this routine has no ef
fect. The current process handle is acquired using
hdl_get_my_process_handle.
DIAGNOSTICS
Return Value
For pm_get_my_pgid: the process group.
For pm_get_my_pid: the process id.
For hdl_get_my_process_handle: the process handle.
For pc_is_interrupted and pc_is_terminated:
TRUE A signal is presented to be handled.
FALSE No signal is present. event_ptr is set to an event
that will occur when it is appropriate to re-check for
termination signals.
Errors
None.
Abort Conditions
None.
SEE ALSO
pm_is_super_user(3K).
Programming in the DG/UX Kernel Environment.
Licensed material--property of copyright holder(s)