svcadm(8)을 검색하려면 섹션에서 8 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
signal(3head)
signal.h(3HEAD) Headers signal.h(3HEAD)
NAME
signal.h, signal - base signals
SYNOPSIS
#include <signal.h>
DESCRIPTION
A signal is an asynchronous notification of an event. A signal is said
to be generated for (or sent to) a process when the event associated
with that signal first occurs. Examples of such events include hardware
faults, timer expiration and terminal activity, as well as the invoca‐
tion of the kill(2) or sigsend(2) functions. In some circumstances, the
same event generates signals for multiple processes. A process may re‐
quest a detailed notification of the source of the signal and the rea‐
son why it was generated. See siginfo.h(3HEAD).
Signals can be generated synchronously or asynchronously. Events di‐
rectly caused by the execution of code by a thread, such as a reference
to an unmapped, protected, or bad memory address can generate SIGSEGV
or SIGBUS; a floating-point exception can generate SIGFPE; and the exe‐
cution of an illegal instruction can generate SIGILL. Such events are
referred to as traps; signals generated by traps are said to be syn‐
chronously generated. Synchronously generated signals are initiated by
a specific thread and are delivered to and handled by that thread.
Signals may also be generated by calling kill(), sigqueue(), sigsend(),
pthread_kill(), or pthread_sigqueue(). Events such as keyboard inter‐
rupts generate signals, such as SIGINT, which are sent to the target
process. Such events are referred to as interrupts; signals generated
by interrupts are said to be asynchronously generated. Asynchronously
generated signals are not directed to a particular thread but are han‐
dled by an arbitrary thread that meets either of the following condi‐
tions:
o The thread is blocked in a call to sigwait(2) whose argument
includes the type of signal generated.
o The thread has a signal mask that does not include the type
of signal generated. See pthread_sigmask(3C). Each process
can specify a system action to be taken in response to each
signal sent to it, called the signal's disposition. All
threads in the process share the disposition. The set of
system signal actions for a process is initialized from that
of its parent. Once an action is installed for a specific
signal, it usually remains installed until another disposi‐
tion is explicitly requested by a call to either sigac‐
tion(), signal() or sigset(), or until the process execs().
See sigaction(2) and signal(3C). When a process execs, all
signals whose disposition has been set to catch the signal
will be set to SIG_DFL. Alternatively, a process may request
that the system automatically reset the disposition of a
signal to SIG_DFL after it has been caught. See sigaction(2)
and signal(3C).
SIGNAL DELIVERY
A signal is said to be delivered to a process when a thread within the
process takes the appropriate action for the disposition of the signal.
Delivery of a signal can be blocked. There are two methods for handling
delivery of a signal in a multithreaded application. The first method
specifies a signal handler function to execute when the signal is re‐
ceived by the process. See sigaction(2). The second method uses sig‐
wait(2) to create a thread to handle the receipt of the signal. The
sigaction() function can be used for both synchronously and asynchro‐
nously generated signals. The sigwait() function will work only for
asynchronously generated signals, as synchronously generated signals
are sent to the thread that caused the event. The sigwait() function is
the recommended for use with a multithreaded application.
SIGNAL MASK
Each thread has a signal mask that defines the set of signals currently
blocked from delivery to it. The signal mask of the main thread is in‐
herited from the signal mask of the thread that created it in the par‐
ent process. The selection of the thread within the process that is to
take the appropriate action for the signal is based on the method of
signal generation and the signal masks of the threads in the receiving
process. Signals that are generated by action of a particular thread
such as hardware faults are delivered to the thread that caused the
signal. See pthread_sigmask(3C) or sigprocmask(2). See alarm(2) for
current semantics of delivery of SIGALRM. Signals that are directed to
a particular thread are delivered to the targeted thread. See
pthread_kill(3C). If the selected thread has blocked the signal, it re‐
mains pending on the thread until it is unblocked. For all other types
of signal generation (for example, kill(2), sigsend(2), terminal activ‐
ity, and other external events not ascribable to a particular thread)
one of the threads that does not have the signal blocked is selected to
process the signal. If all the threads within the process block the
signal, it remains pending on the process until a thread in the process
unblocks it. If the action associated with a signal is set to ignore
the signal then both currently pending and subsequently generated sig‐
nals of this type are discarded immediately for this process.
The determination of which action is taken in response to a signal is
made at the time the signal is delivered to a thread within the
process, allowing for any changes since the time of generation. This
determination is independent of the means by which the signal was orig‐
inally generated.
The signals currently defined by <signal.h> are as follows:
tab(); lw(1.18i) lw(0.39i) lw(0.79i) lw(3.14i) lw(1.18i) lw(0.39i)
lw(0.79i) lw(3.14i) NameValueDefaultEvent SIGHUP1ExitHangup (see
termio(4I)) SIGINT2ExitInterrupt (see termio(4I)) SIGQUIT3CoreQuit (see
termio(4I)) SIGILL4CoreIllegal Instruction SIGTRAP5CoreTrace or Break‐
point Trap SIGABRT6CoreAbort SIGEMT7CoreEmulation Trap SIGFPE8Core‐
Arithmetic Exception SIGKILL9ExitKilled SIGBUS10CoreBus Error
SIGSEGV11CoreSegmentation Fault SIGSYS12CoreBad System Call SIG‐
PIPE13ExitBroken Pipe SIGALRM14ExitAlarm Clock SIGTERM15ExitTerminated
SIGUSR116ExitUser Signal 1 SIGUSR217ExitUser Signal 2 SIGCHLD18Ig‐
noreChild Status Changed SIGPWR19IgnorePower Fail or Restart SIG‐
WINCH20IgnoreWindow Size Change SIGURG21IgnoreUrgent Socket Condition
SIGPOLL22ExitPollable Event (see streamio(4I)) SIGSTOP23StopStopped
(signal) SIGTSTP24StopStopped (user) (see termio(4I)) SIGCONT25Ignore‐
Continued SIGTTIN26StopStopped (tty input) (see termio(4I)) SIGT‐
TOU27StopStopped (tty output) (see termio(4I)) SIGVTALRM28ExitVirtual
Timer Expired SIGPROF29ExitProfiling Timer Expired SIGXCPU30CoreT{ CPU
time limit exceeded (see getrlimit(2)) T} SIGXFSZ31CoreT{ File size
limit exceeded (see getrlimit(2)) T} SIGWAITING32IgnoreReserved SIGAIO‐
CANCEL33IgnoreReserved SIGFREEZE34IgnoreCheck point Freeze SIGTHAW35Ig‐
noreCheck point Thaw SIGCANCEL36IgnoreReserved for threading support
SIGLOST37ExitT{ Resource lost (for example, record-lock lost) T}
SIGXRES38IgnoreT{ Resource control exceeded (see setrctl(2)) T}
SIGJVM139IgnoreReserved for Java Virtual Machine 1 SIGJVM240IgnoreRe‐
served for Java Virtual Machine 2 SIGRTMIN*ExitFirst real time signal
(SIGRTMIN+1)*ExitSecond real time signal ... (SIGRTMAX-1)*ExitSecond-
to-last real time signal SIGRTMAX*ExitLast real time signal
The symbols SIGRTMIN through SIGRTMAX are evaluated dynamically to per‐
mit future configurability.
Applications should not use any of the signals marked "reserved" in the
above table for any purpose, to avoid interfering with their use by the
system.
SIGNAL DISPOSITION
A process using a signal(3C), sigset(3C) or sigaction(2) system call
can specify one of three dispositions for a signal: take the default
action for the signal, ignore the signal, or catch the signal.
Default Action: SIG_DFL
A disposition of SIG_DFL specifies the default action. The default ac‐
tion for each signal is listed in the table above and is selected from
the following:
Exit When it gets the signal, the receiving process is to be ter‐
minated with all the consequences outlined in exit(2).
Core When it gets the signal, the receiving process is to be ter‐
minated with all the consequences outlined in exit(2). In ad‐
dition, a core image of the process is constructed in the
current working directory.
Stop When it gets the signal, the receiving process is to stop.
When a process is stopped, all the threads within the process
also stop executing.
Ignore When it gets the signal, the receiving process is to ignore
it. This is identical to setting the disposition to SIG_IGN.
Ignore Signal: SIG_IGN
A disposition of SIG_IGN specifies that the signal is to be ignored.
Setting a signal action to SIG_IGN for a signal that is pending causes
the pending signal to be discarded, whether or not it is blocked. Any
queued values pending are also discarded, and the resources used to
queue them are released and made available to queue other signals.
Catch Signal: function address
A disposition that is a function address specifies that, when it gets
the signal, the thread within the process that is selected to process
the signal will execute the signal handler at the specified address.
Normally, the signal handler is passed the signal number as its only
argument. If the disposition was set with the sigaction(2) function,
however, additional arguments can be requested. When the signal handler
returns, the receiving process resumes execution at the point it was
interrupted, unless the signal handler makes other arrangements. If an
invalid function address is specified, results are undefined.
If the disposition has been set with the sigset() or sigaction(), the
signal is automatically blocked in the thread while it is executing the
signal catcher. If a longjmp() is used to leave the signal catcher,
then the signal must be explicitly unblocked by the user. See
setjmp(3C), signal(3C) and sigprocmask(2).
If execution of the signal handler interrupts a blocked function call,
the handler is executed and the interrupted function call returns −1 to
the calling process with errno set to EINTR. If the SA_RESTART flag is
set, however, certain function calls will be transparently restarted.
Some signal-generating functions, such as high resolution timer expira‐
tion, asynchronous I/O completion, inter-process message arrival, and
the sigqueue(3C) and pthread_sigqueue(3C) functions, support the speci‐
fication of an application defined value, either explicitly as a para‐
meter to the function, or in a sigevent structure parameter. The
sigevent structure is defined by <signal.h> and contains at least the
following members:
tab(); lw(1.72i) lw(2.06i) lw(1.72i) lw(1.72i) lw(2.06i) lw(1.72i)
TypeNameDescription _ intsigev_notifyNotification type _ intsigev_sig‐
noSignal number _ union sigvalsigev_valueSignal value _ void(*)(union
sigval)sigev_notify_functionNotification function _ (pthread_attr_t
*)sigev_notify_attributesNotification attributes
The sigval union is defined by <signal.h> and contains at least the
following members:
tab(); lw(1.83i) lw(1.83i) lw(1.83i) lw(1.83i) lw(1.83i) lw(1.83i)
TypeNameDescription _ intsival_intInteger signal value _ void
*sival_ptrPointer signal value
The sigev_notify member specifies the notification mechanism to use
when an asynchronous event occurs. The sigev_notify member may be de‐
fined with the following values:
SIGEV_MEM
An asynchronous notification is provided by updating memory loca‐
tion when the event of interest occurs. Currently, supported only
for aio_read(3C) and aio_write(3C) APIs. The memory location to be
updated will be specified by the API that supports it.
SIGEV_NONE
No asynchronous notification is delivered when the event of inter‐
est occurs.
SIGEV_PORT
An asynchronous notification is delivered to an event port when the
event of interest occurs. The sigev_value.sival_ptr member points
to a port_notify_t structure defined in <port.h> (see port_asso‐
ciate(3C)). The event port identifier as well as an application-de‐
fined cookie are part of the port_notify_t structure.
SIGEV_SIGNAL
A queued signal, with its value equal to sigev_signo, is generated
when the event of interest occurs.
SIGEV_SIGNAL_THR
A queued signal directed to the requesting thread, with its value
equal to sigev_signo, is generated when the event of interest oc‐
curs.
SIGEV_THREAD
The sigev_notify_function is called, with sigev_value as its argu‐
ment, to perform notification when the asynchronous event occurs.
The function is executed in an environment as if it were the start
routine for a newly created thread with thread attributes sigev_no‐
tify_attributes. If sigev_notify_attributes is NULL, the thread
runs as a detached thread with default attributes. Otherwise, the
thread runs with the specified attributes, but as a detached thread
regardless. The thread runs with all blockable signals blocked.
The sigev_value member contains the application-defined value to be
passed to the signal-catching function (for notification type
SIGEV_SIGNAL and SIGEV_SIGNAL_THR) at the time of the signal delivery
as the si_value member of the siginfo_t structure, or as the argument
to the notification function (for notification type SIGEV_THREAD) that
is called when the asynchronous event occurs. For notification type
SIGEV_PORT, sigev_value.sival_ptr points to a port_notify_t structure
that specifies the port and an application-defined cookie.
The sival_int member is used when the application defined value is of
type int, and the sival_ptr member is used when the application defined
value is a pointer.
When a signal is generated by sigqueue(3C), pthread_sigqueue(3C), or
any signal−generating function which supports the specification of an
application defined value, the signal is marked pending and, if the
SA_SIGINFO flag is set for that signal, the signal is queued to the
process along with the application specified signal value. Multiple oc‐
currences of signals so generated are queued in FIFO order. If the
SA_SIGINFO flag is not set for that signal, later occurrences of that
signal's generation, when a signal is already queued, are silently dis‐
carded.
ATTRIBUTES
See attributes(7) for descriptions of the following attributes:
tab() box; cw(2.75i) |cw(2.75i) lw(2.75i) |lw(2.75i) ATTRIBUTE TYPEAT‐
TRIBUTE VALUE _ Interface StabilityCommitted _ StandardSee stan‐
dards(7).
SEE ALSO
alarm(2), exit(2), fcntl(2), getrlimit(2), Intro(2), ioctl(2), kill(2),
pause(2), setrctl(2), sigaction(2), sigaltstack(2), sigprocmask(2),
sigsend(2), sigsuspend(2), sigwait(2), port_associate(3C), pthread_cre‐
ate(3C), pthread_kill(3C), pthread_sigmask(3C), pthread_sigqueue(3C),
setjmp(3C), signal(3C), sigqueue(3C), sigsetops(3C), timer_create(3C),
wait(3C), siginfo.h(3HEAD), ucontext.h(3HEAD), attributes(7), stan‐
dards(7), lockd(8)
NOTES
The dispositions of the SIGKILL and SIGSTOP signals cannot be altered
from their default values. The system generates an error if this is at‐
tempted.
The SIGKILL, SIGSTOP, and SIGCANCEL signals cannot be blocked. The sys‐
tem silently enforces this restriction.
The SIGCANCEL signal cannot be directed to an individual thread using
pthread_kill(3C) or pthread_sigqueue(3C), but it can be sent to a
process using kill(2), sigsend(2), or sigqueue(3C).
Whenever a process receives a SIGSTOP, SIGTSTP, SIGTTIN, or SIGTTOU
signal, regardless of its disposition, any pending SIGCONT signal are
discarded.
Whenever a process receives a SIGCONT signal, regardless of its dispo‐
sition, any pending SIGSTOP, SIGTSTP, SIGTTIN, and SIGTTOU signals is
discarded. In addition, if the process was stopped, it is continued.
SIGPOLL is issued when a file descriptor corresponding to a STREAMS
file has a "selectable" event pending. See Intro(2). A process must
specifically request that this signal be sent using the I_SETSIG ioctl
call. Otherwise, the process will never receive SIGPOLL.
If the disposition of the SIGCHLD signal has been set with signal() or
sigset(), or with sigaction() and the SA_NOCLDSTOP flag has been speci‐
fied, it will only be sent to the calling process when its children
exit; otherwise, it will also be sent when the calling process's chil‐
dren are stopped or continued due to job control.
The name SIGCLD is also defined in this header and identifies the same
signal as SIGCHLD. SIGCLD is provided for backward compatibility, new
applications should use SIGCHLD.
The disposition of signals that are inherited as SIG_IGN should not be
changed.
Signals which are generated synchronously should not be masked. If such
a signal is blocked and delivered, the receiving process is killed.
Oracle Solaris 11.4 1 Nov 2023 signal.h(3HEAD)