*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->IRIX man pages -> signal (5)              


SIGNAL(5)							     SIGNAL(5)

NAME    [Toc]    [Back]

     signal - base signals

SYNOPSIS    [Toc]    [Back]

     #include <signal.h>

DESCRIPTION    [Toc]    [Back]

     A signal is an asynchronous notification of an event.  A signal is	said
     to	be generated for (or sent to) a	process	or a thread 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 invocation of the kill(2), sigqueue(3) or sigsend(2) system	calls.
     In	some circumstances, the	same event generates signals for multiple
     processes.	 A process may request a detailed notification of the source
     of	the signal and the reason why it was generated [see siginfo(5)].

     At	the time of generation,	the system will	determine whether the signal
     is	directed at a process or a specific thread within that process.
     Signals that are naturally	associated with	a particular thread, such as
     hardware faults, are directed to the appropriate thread.  This is usually
     due to the	signal being generated during the execution of the thread and,
     moreover, in the context of executing that	thread.	 Signals that are sent
     to	a process tend to be those that	are generated asynchronously with
     respect to	the execution of the process.  Signals generated by the	kill
     interface or sent as a result of a	tty interrupt are examples of signals
     directed at a process.

     Each process may specify a	system action to be taken in response to each
     signal sent to it,	called the signal's disposition.  For multithreaded
     processes,	the disposition	is shared by all threads in the	process.  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 disposition is explicitly
     requested by a call to either sigaction(2), signal(2), signal(3B),
     sigvec(3B)	or sigset(2), or until the process execs [see sigaction(2) and
     signal(2)].  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

     A signal is said to be delivered to a process or thread when the
     appropriate action	for the	signal is taken.  During the time between the
     generation	of a signal and	its delivery, the signal is said to be pending
     [see sigpending(2)].  Ordinarily, this interval cannot be detected	by an
     application.  However, a signal can be blocked from delivery to a thread
     [see sighold(2), sigblock(3) and sigprocmask(2)].	If the action
     associated	with a blocked signal is anything other	than to	ignore the
     signal, and if that signal	is generated for the process or	thread,	the
     signal remains pending until either it is unblocked or the	signal's
     disposition requests that the signal be ignored.  Signals generated for
     the process shall be delivered to exactly one of the threads within the

									Page 1

SIGNAL(5)							     SIGNAL(5)

     process.  The thread must either be executing the sigwait function
     selecting that signal or it must not be blocking delivery of the signal.
     If	there are no threads in	a call to a sigwait function selecting that
     signal, and if all	threads	within the process block delivery of the
     signal, the signal	shall remain pending of	the process until either a
     thread calls a sigwait function selecting that signal, a thread unblocks
     delivery of that signal, or the action associated with the	signal is set
     to	ignore the signal.  If the signal disposition of a blocked signal
     requests that the signal be ignored, and if that signal is	generated for
     the process or thread, the	signal is discarded immediately	upon

     On	IRIX, a	pending	signal is usually delivered when a thread returns from
     the kernel. This happens at the end of a system call or at	the end	of a
     hardware interrupt. Since the scheduling clock interrupt occurs at	a
     regular 10	msec interval, this means that the latency between the
     generation	of a signal and	its delivery can never be more than 10 msec.
     For real-time application(defined as process with high band non-degrading
     priority),	a generation of	a signal always	force an immediate signal

     Each thread has a signal mask that	defines	the set	of signals currently
     blocked from delivery to it [see sigprocmask(2) or	pthread_sigmask(3P)].
     The signal	mask for a thread is initialized from the thread that created

     The determination of which	action is taken	in response to a signal	is
     made at the time the signal is delivered, allowing	for any	changes	since
     the time of generation.  This determination is independent	of the means
     by	which the signal was originally	generated.

     The signals currently defined in signal.h are as follows:

    Name	 Value	 Default   Event
    SIGHUP	 1	 Exit	   Hangup [see termio(7)]
    SIGINT	 2	 Exit	   Interrupt [see termio(7)]
    SIGQUIT	 3	 Core	   Quit	[see termio(7)]
    SIGILL	 4	 Core	   Illegal Instruction
    SIGTRAP	 5	 Core	   Trace, Breakpoint, Range Error
				   Divide by Zero, or Overflow Trap
    SIGABRT	 6	 Core	   Abort
    SIGEMT	 7	 Core	   Emulation Trap
    SIGFPE	 8	 Core	   Arithmetic Exception
    SIGKILL	 9	 Exit	   Killed
    SIGBUS	 10	 Core	   Bus Error
    SIGSEGV	 11	 Core	   Segmentation	Fault
    SIGSYS	 12	 Core	   Bad System Call
    SIGPIPE	 13	 Exit	   Broken Pipe
    SIGALRM	 14	 Exit	   Alarm Clock

									Page 2

SIGNAL(5)							     SIGNAL(5)

    SIGTERM	 15	 Exit	   Terminated
    SIGUSR1	 16	 Exit	   User	Signal 1
    SIGUSR2	 17	 Exit	   User	Signal 2
    SIGCHLD	 18	 Ignore	   Child Status	Changed
    SIGPWR	 19	 Ignore	   Power Fail/Restart
    SIGWINCH	 20	 Ignore	   Window Size Change
    SIGURG	 21	 Ignore	   Urgent Socket Condition
    SIGPOLL	 22	 Exit	   Pollable Event [see streamio(7)]
    SIGIO	 22	 Exit	   input/output	possible signal
    SIGSTOP	 23	 Stop	   Stopped (signal)
    SIGTSTP	 24	 Stop	   Stopped (user) [see termio(7)]
    SIGCONT	 25	 Ignore	   Continued
    SIGTTIN	 26	 Stop	   Stopped (tty	input) [see termio(7)]
    SIGTTOU	 27	 Stop	   Stopped (tty	output)	[see termio(7)]
    SIGVTALRM	 28	 Exit	   Virtual Timer Expired
    SIGPROF	 29	 Exit	   Profiling Timer Expired
    SIGXCPU	 30	 Core	   CPU time limit exceeded [see	getrlimit(2)]
    SIGXFSZ	 31	 Core	   File	size limit exceeded [see getrlimit(2)]
    SIGCKPT	 33	 Ignore	   Checkpoint warning [see cpr(1)]
    SIGRESTART	 34	 Ignore	   Restart warning [see	cpr(1)]
    SIGRTMIN	 49	 Exit	   POSIX 1003.1b SIGRTMIN
    SIGRTMAX	 64	 Exit	   POSIX 1003.1b SIGRTMAX

     IRIX supports all signal numbers between 0	and 64.	All signals between 0
     and 32 are	currently used.	POSIX 1003.1b reserves all signals between
     SIGRTMIN and SIGRTMAX for real-time applications.	Even though the	kernel
     does not use any signals between 35 and 64, signal	number between 35 and
     49	are not	guaranteed to be available to user programs in future
     releases. Further more, the default behavior for signals between 35 and
     49	is to exit.

     No	signals	beyond 32 are applicable to the	Berkeley signal	functions
     because these functions use a fixed 32 bits signal	mask as	part the
     programming interface.

     Higher priority signals are delivered first when multiple unblocked
     signals are pending in order to prioritize	event notifications. On	the
     other hand, a lower priority signal can not preempt a higher priority
     signal handler.

     All signals between 0 and 32 are of equal priority	but all	are at higher
     priority than signals between SIGRTMIN and	SIGRTMAX.  Within the range of
     SIGRTMIN to SIGRTMAX, the lower the signal	number the higher the priority
     of	that signal.

     Using the signal(2), signal(3B), sigset(2), sigvec(3B)  or	sigaction(2)
     system call, a process may	specify	one of three dispositions for a
     signal:  take the default action for the signal, ignore the signal, or
     catch the signal.

									Page 3

SIGNAL(5)							     SIGNAL(5)

   Default Action: SIG_DFL
     A disposition of SIG_DFL specifies	the default action.  The default
     action 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
	     abnormally	terminated with	all the	consequences outlined in

     Core    When it gets the signal, the receiving process is to be
	     abnormally	terminated with	all the	consequences outlined in
	     _exit(2).	In addition, 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.

     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.

   Catch Signal: function address
     A disposition that	is a function address specifies	that, when it gets the
     signal, the receiving thread is to	execute	the signal handler at the
     specified address.	Under IRIX, there are two ways a signal	handler	can be
     delivered.	 If SA_SIGINFO is set in the field sa_flags of the sigaction_t
     structure during a	previous call to the sigaction(2) function for the
     signal being delivered, the signal	handler	will be	invoked	as follows:

	  handler (int sig, siginfo_t *sip, ucontext_t *up);

     otherwise the signal handler will be invoked as follows:

	  handler (int sig, int	code, struct sigcontext	*sc);

     Where handler is the specified signal handler function-name.  Due to
     historic implementations, signal handlers have been defined with zero,
     one, or three parameters.	To avoid source	incompatibilities, in C, the
     prototype for the signal handler has intentionally	been left empty.  C++
     requires a	prototype, so a	compromise must	be made.  C++ user's should
     cast their	handler	to the type SIG_PF in order to be portable.

     Please see	siginfo(5) and ucontext(5) for more details on the meanings of
     the passed	in parameters of the first form.  The second form is the
     default system behavior.

     In	the second form, code is valid only in the following cases:

     Condition			      Signal	  Code

     User breakpoint		      SIGTRAP	  BRK_USERBP

									Page 4

SIGNAL(5)							     SIGNAL(5)

     User breakpoint		      SIGTRAP	  BRK_SSTEPBP
     Integer overflow		      SIGFPE	  BRK_OVERFLOW
     Divide by zero		      SIGFPE	  BRK_DIVZERO
     Multiply overflow		      SIGFPE	  BRK_MULOVF
     Invalid virtual address	      SIGSEGV	  EFAULT
     Read-only address		      SIGSEGV	  EACCES
     Read beyond mapped	object	      SIGSEGV	  ENXIO
     Autogrow for file failed	      SIGSEGV	  ENOSPC
     Automatic memory lock failed     SIGSEGV	  ENOMEM

     Integer divide by zero, multiply overflow,	integer	overflow, and range
     errors are	special	cases. If the binary is	not an IRIX 4 binary and a
     signal handler is installed for SIGFPE then the SIGFPE handler is called,
     otherwise SIGTRAP is called. This behavior	is included to keep older IRIX
     4 and IRIX	5 binaries working, however the	correct	way to code a handler
     is	to use SIGFPE.

     The third argument	sc of the second form is a pointer to a	struct
     sigcontext	(defined in <sys/signal.h>) that contains the processor
     context at	the time of the	signal.

     When the signal handler returns, the receiving thread resumes execution
     at	the point it was interrupted, unless the signal	handler	makes other
     arrangements.  If an invalid function address is specified, results are

     If	the disposition	has been set with the signal(3B), sigset(2),
     sigvec(3B)	or sigaction(2)	function, the signal is	automatically blocked
     by	the system while the signal catcher is executing.  If a	longjmp	[see
     setjmp(3C)] is used to leave the signal catcher, then the signal must be
     explicitly	unblocked by the user [see sigrelse(2),	sigprocmask(2),	and

     If	execution of the signal	handler	interrupts a blocked system call, the
     handler is	executed and the interrupted system call returns a -1 to the
     calling thread with errno set to EINTR.  However, if the SA_RESTART flag
     is	set the	system call will be transparently restarted.

NOTES    [Toc]    [Back]

     The dispositions of the SIGKILL and SIGSTOP signals cannot	be altered
     from their	default	values.	 The system generates an error if this is

     The SIGKILL and SIGSTOP signals cannot be blocked.	 The system silently
     enforces this restriction.

     Whenever a	process	receives a SIGSTOP, SIGTSTP, SIGTTIN, or SIGTTOU
     signal, regardless	of its disposition, any	pending	SIGCONT	signal are
     discarded.	Further	more, the process will not act upon any	delivered
     signals other than	SIGKILL	until a	SIGCONT	is received.

									Page 5

SIGNAL(5)							     SIGNAL(5)

     Whenever a	process	receives a SIGCONT signal, regardless of its
     disposition, any pending SIGSTOP, SIGTSTP,	SIGTTIN, and SIGTTOU signals
     is	discarded.  In addition, if the	process	was stopped, it	is continued.

     When a signal is delivered	to a thread, if	the action of that signal
     specifies termination, stop, or continue, all the threads in the process
     shall be terminated, stopped, or continued, respectively.

     Processes which are blocked via a blockproc system	call will unblock if
     they receive a signal which is fatal (i.e., a non-job-control signal
     which the are NOT catching), but will still be stopped if the job of
     which they	are a part is stopped.	Only upon restart will they die.  Any
     non-fatal signals received	by a blocked process will NOT cause the
     process to	be unblocked (an unblockproc(2)	or unblockprocall(2) system
     call is necessary).

     SIGPOLL is	issued when a file descriptor corresponding to a STREAMS [see
     intro(2)] file has	a ``selectable'' event pending.	 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,	sigvec
     or	sigset,	or with	sigaction and the SA_NOCLDSTOP flag has	been
     specified,	it will	only be	sent to	the calling process when its children
     exit; otherwise, it will also be sent when	the calling process's children
     are stopped or continued due to job control.

     The name SIGCLD is	also defined in	this header file 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

     A call to signal cancels a	pending	signal sig except for a	pending
     SIGKILL signal.

     A call to sigset with a signal handler other than SIG_IGN will
     automatically allow pending signals for the set signal to come in.

SEE ALSO    [Toc]    [Back]

     exit(2), getrlimit(2), intro(2), kill(2), pause(2), pthread_kill(3P),
     pthread_sigmask(3P), sigaction(2),	sigaltstack(2),	signal(2), sigset(2),
     signal(3B), sigprocmask(2), sigsend(2), sigqueue(3), sigsuspend(2),
     wait(2), sigsetops(3C), siginfo(5), ucontext(5)

									PPPPaaaaggggeeee 6666
[ Back ]
 Similar pages
Name OS Title
signal HP-UX description of signals
sigpending OpenBSD get pending signals
sigmask OpenBSD block signals
ssignal IRIX software signals
sigwait FreeBSD select a set of signals
sigblock HP-UX block signals
sigblock OpenBSD block signals
sigpending FreeBSD get pending signals
sigpending NetBSD get pending signals
signal Linux list of available signals
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service