process_management(3K) DG/UX 5.4R3.00 process_management(3K)
NAME
process_management: pm_get_my_pid, pm_get_my_pgid, 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"
gid_t pm_get_my_pgid ()
pid_t pm_get_my_pid ()
boolean_type pc_is_interrupted (event_ptr)
vp_event_ptr_type event_ptr; /*WRITE ONLY*/
boolean_type pc_is_terminated (event_ptr)
vp_event_ptr_type event_ptr; /*WRITE ONLY*/
void sig_kernel_send_to_process_group_id (pid_t
target_group, sig_signal_number_type
signal_number)
void sig_kernel_send_to_process
(pc_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. Can be
pc_my_process_handle.
process_group The process group ID of the target process group.
process_id The process ID of the target.
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
pc_is_interrupted Handle signals during a system call
pc_is_terminated Check for 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
Licensed material--property of copyright holder(s) 1
process_management(3K) DG/UX 5.4R3.00 process_management(3K)
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 you 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 read your
LWP's process handle from a per-LWP variable called
pc_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 find out about both normal and terminate sig
nals. You call pc_is_terminated to ask about terminate signals only.
Though you must query for the signal, signals may also be processed
in conjunction with events. If a signal is present, the query rou
tine (for example, pc_is_interrupted) returns a flag indicating the
signal is present and you process the signal. If a signal is not
present, the flag is FALSE and the query routine returns an event.
You can use this event to suspend and wait for the signal. To do so
you add the event to the list of events to be awaited and call
vp_await_ec. Generally, the event will be satisfied when a signal
occurs but this is not always the case. Therefore, when the event is
satisfied, you should verify that a signal has occurred by calling
the query routine again.
Note that pc_is_interrupted may suspend the calling LWP for an arbi
trary amount of time and should only be used when an indefinite wait
is possible. For example, if a process that is being debugged re
ceives 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.
Licensed material--property of copyright holder(s) 2
process_management(3K) DG/UX 5.4R3.00 process_management(3K)
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.
pc_is_interrupted
This routine handles signals during a system call.
This routine handles signal processing. It should be used whenever a
system call will pend the calling LWP until some external event oc
curs (that is, pend for an arbitrary amount of time). Processing in
cludes 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[PROCESS_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 PROCESS_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. In addition, the event returned by
pc_is_interrupted is also important. If the calling LWP is inter
rupted, the system call will return an error and will set errno to
EINTR. Otherwise, the system call pends until the calling LWP is in
terrupted or one of the relevant events has happened.
Licensed material--property of copyright holder(s) 3
process_management(3K) DG/UX 5.4R3.00 process_management(3K)
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 in pc_my_process_handle.
DIAGNOSTICS
Return Value
For pm_get_my_pgid: the process group.
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) 4