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

  man pages->IRIX man pages -> standard/sigaction (2)              
Title
Content
Arch
Section
 

Contents


SIGACTION(2)							  SIGACTION(2)


NAME    [Toc]    [Back]

     sigaction - software signal facilities (POSIX)

SYNOPSIS    [Toc]    [Back]

     #include <signal.h>

     C:
       struct sigaction	{
	  int sa_flags;
	  union	{
	       void (*sa_handler)();
	       void (*sa_sigaction)(int, siginfo_t *, void *);
	  }
	  sigset_t sa_mask;
       };

     C++:
       struct sigaction	{
	  int sa_flags;
	  union	{
	       void (*sa_handler)(int);
	       void (*sa_sigaction)(int, siginfo_t *, void *);
	  }
	  sigset_t sa_mask;
       };

     int sigaction(int sig, struct sigaction *act,
			    struct sigaction *oact);

DESCRIPTION    [Toc]    [Back]

     sigaction specifies and reports on	the way	individual signals are to be
     handled in	the calling process.

     sig specifies the signal and can be assigned any of the signals specified
     in	signal(5).

     If	act is non-zero, it points to a	structure specifying the new action to
     be	taken when delivering sig. If oact is non-zero,	the previous handling
     information for the signal	is returned to the user.  In this way (a NULL
     act and a non-NULL	oact) the user can enquire as to the current handling
     of	a signal without changing it.  If both act and oact are	NULL,
     sigaction will return EINVAL if sig is an invalid signal (else 0),
     allowing an application to	dynamically determine the set of signals
     supported by the system.

     If	the SA_SIGINFO flag is clear in	sa_flags then sa_handler specifies the
     disposition of the	signal and may take any	of the values specified	in
     signal(5).

     If	the SA_SIGINFO flag is set in sa_flags then sa_sigaction specifies the
     disposition of the	signal and may take a pointer to a function.




									Page 1






SIGACTION(2)							  SIGACTION(2)



     sa_mask specifies a set of	signals	to be blocked while the	signal handler
     is	active.	On entry to the	signal handler,	that set of signals is added
     to	the set	of signals already being blocked when the signal is delivered.
     In	addition, the signal that caused the handler to	be executed will also
     be	blocked, unless	the SA_NODEFER flag has	been specified.	 Keep in mind
     that SA_NODEFER is	superseded by sa_mask so that if SA_NODEFER is set but
     the same signal is	specified in sa_mask, the signal will still be
     blocked.  SIGSTOP and SIGKILL cannot be blocked (the system silently
     enforces this restriction).  The user constructs this mask	via the
     routines described	in sigsetops(3).

     The sa_flags field	specifies a set	of flags used to modify	the delivery
     of	the signal.  It	is formed by a logical OR of any of the	following
     values:

	  SA_ONSTACK   If set and the signal is	caught and an alternate	signal
		       stack has been declared with sigaltstack(2), the	signal
		       is delivered to the calling process on that stack.
		       Otherwise, the signal is	delivered on the same stack as
		       the main	program.

	  SA_RESETHAND If set and the signal is	caught,	the disposition	of the
		       signal is reset to SIG_DFL (SIGILL, SIGTRAP, and	SIGPWR
		       cannot be automatically reset when delivered; the
		       system silently enforces	this restriction).

	  SA_NODEFER   If set and the signal is	caught,	the signal will	not be
		       automatically blocked by	the kernel while it is being
		       caught.

	  SA_RESTART   If set and the signal is	caught,	a system call that is
		       interrupted by the execution of this signal's handler
		       is transparently	restarted by the system.  Otherwise,
		       that system call	returns	an EINTR error.

	  SA_SIGINFO   If set and the signal is	caught,	sig is passed as the
		       first argument to the signal-catching function.	If the
		       second argument is not equal to NULL, it	points to a
		       siginfo_t structure containing the reason why the
		       signal was generated [see siginfo(5)]; the third
		       argument	points to a ucontext_t structure containing
		       the receiving process's context when the	signal was
		       delivered [see ucontext(5)].  If	cleared	and the	signal
		       is caught, the first argument is	also the signal	number
		       but the second argument is the signal code identifying
		       the cause of the	signal.	The third argument points to a
		       sigcontext_t structure containing the receiving
		       process's context when the signal was delivered.	This
		       is the default behavior (see signal(5) for more
		       details).  Additionally,	when SA_SIGINFO	is set for a
		       signal, multiple	occurrences of that signal will	be
		       queued for delivery in FIFO order (see sigqueue(3) for



									Page 2






SIGACTION(2)							  SIGACTION(2)



		       a more detailed explanation of this concept), if	those
		       occurrences of that signal were generated using
		       sigqueue(3).

	  SA_NOCLDWAIT If set and sig equals SIGCHLD, the system will not
		       create zombie processes when children of	the calling
		       process exit.  If the calling process subsequently
		       issues a	wait(2), it blocks until all of	the calling
		       process's child processes terminate, and	then returns a
		       value of	-1 with	errno set to ECHILD.

	  SA_NOCLDSTOP If set and sig equals SIGCHLD, sig will not be sent to
		       the calling process when	its child processes stop or
		       continue.

     sigaction will fail and no	new signal handler will	be installed if	one of
     the following occurs:

     [EFAULT]  Either act or oact points to memory that	is not a valid part of
	       the process address space.

     [EINVAL]  sig is not a valid signal number.

     [EINVAL]  An attempt is made to ignore or supply a	handler	for SIGKILL or
	       SIGSTOP.

     [EINVAL]  An attempt is made to ignore SIGCONT (by	default	SIGCONT	is
	       ignored).

SEE ALSO    [Toc]    [Back]

      
      
     blockproc(2), kill(2), signal(2), sigprocmask(2), sigpending(2),
     sigsuspend(2), sigwait(2),	sigsetjmp(3), sigset(2), setrlimit(2),
     ulimit(2),	wait(2), sigsetops(3), sigvec(3B), signal(5).

DIAGNOSTICS    [Toc]    [Back]

     A 0 value indicates that the call succeeded.  A -1	return value indicates
     an	error occurred and errno is set	to indicate the	reason.

WARNINGS    [Toc]    [Back]

     Signals raised by any instruction in the instruction stream, including
     SIGFPE, SIGILL, SIGEMT, SIGBUS, and SIGSEGV, will cause infinite loops if
     their handler returns, or the action is set to SIG_IGN. This is because
     the exception PC at the time of the signal	points to the instruction that
     raised the	exception or signal, and resuming the process will re-execute
     that same instruction.

     The POSIX signal routines (sigaction(2), sigpending(2), sigprocmask(2),
     sigsuspend(2), sigsetjmp(3)), and the 4.3BSD signal routines (sigvec(3B),
     signal(3B), sigblock(3B), sigpause(3B), sigsetmask(3B)) must NEVER	be
     used with signal(2) or sigset(2).





									Page 3






SIGACTION(2)							  SIGACTION(2)



     In	multithreaded processes, sigaction cannot be used to predictably
     affect another thread waiting for the affected signals via	sigwait.


									PPPPaaaaggggeeee 4444
[ Back ]
 Similar pages
Name OS Title
sigvec OpenBSD software signal facilities
sigvec NetBSD software signal facilities
sigvector HP-UX software signal facilities
sigaction NetBSD software signal facilities
sigaction OpenBSD software signal facilities
sigaction FreeBSD software signal facilities
sigvec FreeBSD software signal facilities
sigvec Linux BSD software signal facilities
sigvec IRIX 4.3BSD software signal facilities
signal NetBSD simplified software signal facilities
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service