SIGNAL

Portability Function: Controls interrupt signal handling. Changes the action for a specified signal.

Module: USE DFPORT

Syntax

result = SIGNAL (signum, proc, flag)

signum
(Input) INTEGER(4). Number of the signal to change. The numbers and symbolic names are listed in a table below.

proc
(Input) Name of a signal-processing routine. It must be declared EXTERNAL. This routine is called only if flag is negative.

flag
(Input) INTEGER(4). If negative, the user's proc routine is called. If 0, the signal retains its default action; if 1, the signal should be ignored.

Results:

The result is of type INTEGER(4). The result is the previous value of proc associated with the specified signal. For example, if the previous value of proc was SIG_IGN, the return value is also SIG_IGN. You can use this return value in subsequent calls to SIGNAL if the signal number supplied is invalid, if the flag value is greater than 1, or to restore a previous action definition.

A return value of SIG_ERR indicates an error, in which case a call to IERRNO returns EINVAL. If the signal number supplied is invalid, or if the flag value is greater than 1, SIGNAL returns -(EINVAL) and a call to IERRNO returns EINVAL.

An initial signal handler is in place at startup for SIGFPE (signal 8); its address is returned the first time SIGNAL is called for SIGFPE. No other signals have initial signal handlers.

Be careful when you use SIGNALQQ or the C signal function to set a handler, and then use the Portability SIGNAL function to retrieve its value. If SIGNAL returns an address that was not previously set by a call to SIGNAL, you cannot use that address with either SIGNALQQ or C's signal function, nor can you call it directly. You can, however, use the return value from SIGNAL in a subsequent call to SIGNAL. This allows you to restore a signal handler, no matter how the original signal handler was set.

All signal handlers are called with a single integer argument, that of the signal number actually received. Usually, when a process receives a signal, it terminates. With the SIGNAL function, a user procedure is called instead. The signal handler routine must accept the signal number integer argument, even if it does not use it. If the routine does not accept the signal number argument, the stack will not be properly restored after the signal handler has executed.

Because signal-handler routines are usually called asynchronously when an interrupt occurs, it is possible that your signal-handler function will get control when a run-time operation is incomplete and in an unknown state. There are certain restrictions as to which functions you can use in your signal-handler routine:

• Do not do either low-level (such as FGETC) or high-level (such as READ) I/O.
• Do not call heap routines or any routine that uses the heap routines (such as MALLOC and ALLOCATE).
• Do not use any function that generates a system call (such as TIME).

SIGKILL can be neither caught nor ignored.

The following table lists signals, their names and values:

The default action for all signals is to terminate the program with exit code.

ABORT does not assert the SIGABRT signal. The only way to assert SIGABRT or SIGTERM is to use KILL.

SIGNAL can be used to catch SIGFPE exceptions, but it cannot be used to access the error code that caused the SIGFPE. To do this, use SIGNALQQ instead.

Compatibility

CONSOLE STANDARD GRAPHICS QUICKWIN GRAPHICS WINDOWS DLL LIB

See Also: SIGNALQQ

Example

    USE dfport
    EXTERNAL h_abort
    INTEGER(4) iret1, iret2, procnum
    iret1 = SIGNAL(SIGABRT, h_abort, -1)
    WRITE(*,*) 'Set signal handler. Return = ', iret1

    iret2 = KILL(procnum, SIGABRT)
    WRITE(*,*) 'Raised signal. Return = ', iret2
    END
 !
 !  Signal handler routine
 !
    INTEGER(4) FUNCTION h_abort (sig_num)
    INTEGER(4) sig_num

    WRITE(*,*) 'In signal handler for SIG$ABORT'
    WRITE(*,*) 'signum = ', sig_num
    h_abort = 1
    END