process_management(3K) DG/UX 5.4R3.00 process_management(3K)
NAME
processmanagement: pmgetmypid, pmgetmypgid, pcisinterrupted,
pcisterminated, sigkernelsendtoprocessgroupid,
sigkernelsendtoprocess - manage processes and signals
SYNOPSIS
#include "/usr/src/uts/aviion/ii/ipm.h"
#include "/usr/src/uts/aviion/ii/ipc.h"
#include "/usr/src/uts/aviion/ii/isig.h"
gidt pmgetmypgid ()
pidt pmgetmypid ()
booleantype pcisinterrupted (eventptr)
vpeventptrtype eventptr; /*WRITE ONLY*/
booleantype pcisterminated (eventptr)
vpeventptrtype eventptr; /*WRITE ONLY*/
void sigkernelsendtoprocessgroupid (pidt
targetgroup, sigsignalnumbertype
signalnumber)
void sigkernelsendtoprocess
(pcprocesshandletype targethandle,
sigsignalnumbertype signalnumber)
where:
eventptr The address of a LWP's interrupt event.
handle The subject process' handle. Can be
pcmyprocesshandle.
processgroup The process group ID of the target process group.
processid The process ID of the target.
signalnumber The number of the signal being sent.
DESCRIPTION
The following routines are described in this man page:
pmgetmypid Return process ID of the calling LWP's
process
pmgetmypgid Return calling LWP's process group
pcisinterrupted Handle signals during a system call
pcisterminated Check for termination signals during a
system call
sigkernelsendtoprocessgroupid
Send a signal to a process group
sigkernelsendtoprocess 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: sigkernelsendtoprocess, and
sigkernelsendtoprocessgroupid. 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 sigkernelsendtoprocess 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 pmgetmypid or pmgetmypgid, respectively. You can read your
LWP's process handle from a per-LWP variable called
pcmyprocesshandle.
You must query the kernel to find out if you have a signal pending.
You query for any pending signals using the pcisinterrupted and
pcisterminated 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
pcisinterrupted to find out about both normal and terminate sig
nals. You call pcisterminated 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, pcisinterrupted) 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
vpawaitec. 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 pcisinterrupted 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
pcisinterrupted (see ptrace(2)). Because of this,
pcisinterrupted 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 pcisinterrupted.
pcisterminated 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. pcisterminated 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.
pmgetmypgid
This routine returns the process group of the calling LWP.
pmgetmypid
This routine returns the process id of the calling LWP.
pcisinterrupted
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
pcisinterrupted routine. The first two actions are performed in
cooperation with the caller.
Typically, you will use the following code fragment:
if (pcisinterrupted(&events[PROCESSINTERRUPT]))
{
Arrange to return EINTR to the user. Exit with error EINTR.
}
vpawaitec(events, N, &index);
Act on the event that was satisfied.
If only the PROCESS_INTERRUPT was satisfied, loop back to
pcisinterrupted().
In the code shown above, the relevant events are those in the
events[] array in the first line. In addition, the event returned by
pcisinterrupted 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)
pcisterminated
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.
sigkernelsendtoprocessgroupid
This routine sends a signal to a process group.
The routine sends the signal signalnumber to the processes whose
process group ID is processgroup. 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.
sigkernelsendtoprocess
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 pcmyprocesshandle.
DIAGNOSTICS
Return Value
For pmgetmypgid: the process group.
For pcisinterrupted and pcisterminated:
TRUE A signal is presented to be handled.
FALSE No signal is present. eventptr 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
pmissuperuser(3K).
Programming in the DG/UX Kernel Environment.
Licensed material--property of copyright holder(s) 4