Psigaction

Section: May 1, 1992 (2)
Updated: MiNT Programmer's Manual
Index Return to Main Contents
 

NAME

Psigaction - change the way a signal is handled  

SYNOPSIS

#include <signal.h>

LONG Psigaction(WORD sig, struct sigaction *act, struct sigaction *oact);
 

DESCRIPTION

Psigaction changes the handling of the signal indicated by sig (which must be between 1 and 31; symbolic constants for symbols are defined in the file signal.h).

If act is non-zero, then it is assumed to point to a structure describing the signal handling behavior. This structure has the following members:

struct sigaction {
        LONG    sa_handler;
        LONG    sa_mask;
        WORD    sa_flags;
}
If sa_handler is SIG_DFL, then the default action for the signal will occur when the signal is delivered to the process.

If sa_handler is SIG_IGN, then the signal will be ignored by the process, and delivery of the signal will have no noticeable effect (in particular, the signal will not interrupt the Pause or Psigpause system calls, q.v.). If the signal is pending at the time of the Psignal call, it is discarded.

If sa_handler is some other value, it is assumed to be the address of a user function that will be called when the signal is delivered to the process. The user function is called with a single LONG argument on the stack, which is the number of the signal being delivered (this is done so that processes may use the same handler for a number of different signals). While the signal is being handled, it is blocked from delivery; thus, signal handling is "reliable" (unlike Version 7 and early System V Unix implementations, in which delivery of a second signal while it was being handled could kill the process). The set of signals specified in sa_mask are also blocked from delivery while the signal handler is executing. Note that, unlike in some versions of Unix, the signal handling is not reset to the default action before the handler is called; it remains set to the given signal handler.

The signal handler must either return (via a normal 680x0 rts instruction) or call the Psigreturn system call to indicate when signal handling is complete; in both cases, the signal will be unblocked. Psigreturn also performs some internal clean-up of the kernel stack that is necessary if the signal handler is not planning to return (for example, if the C longjmp() function is to be used to continue execution at another point in the program).

Signal handlers may make any GEMDOS, BIOS, or XBIOS system calls freely. GEM AES and VDI calls should not be made in a signal handler.

The sa_flags field specifies additional, signal-specific signal handling behavior. If sig is SIGCHLD, and the SA_NOCLDSTOP bit is set in sa_flags, then the SIGCHLD signal is sent to this process only when one of its children terminates (and not when a child is suspended by a job control signal).

The oact argument to Psigaction, if non-zero, specifies a structure that will be set to reflect the signal handling for sig that was current at the time of the Psigaction system call.

Note that calling Psigaction to change behavior of a signal has the side effect of unmasking that signal, so that delivery is possible. This is done so that processes may, while handling a signal, reset the behavior and send themselves another instance of the signal, for example in order to suspend themselves while handling a job control signal. Signal handling is preserved across Pfork and Pvfork calls. Signals that are ignored by the parent are also ignored by the child after a Pexec call; signals that were being caught for handling in a function are reset in the child to the default behavior.  

RETURNS

0 on success

ERANGE if sig is not a legal signal.

EACCDN if the signal may not be caught by the user  

SEE ALSO

Pkill(2), Psigblock(2), Psignal(2), Psigreturn(2)  

BUGS

Signal handling can be nested only a small (around 3) number of times, i.e. if 4 signals are delivered to a process, and the process has established handlers for all 4, and none of the handlers has returned or called Psigreturn,
 then there is a very good chance of a stack overflow killing the process off. In practice, this is unlikely to happen.  

AUTHOR

Alex Kiernan


 

Index

NAME
SYNOPSIS
DESCRIPTION
RETURNS
SEE ALSO
BUGS
AUTHOR

This document was created by man2html, using the manual pages.
Time: 23:26:11 GMT, January 03, 2023