Signal handling on UNIX

[AndyS|Dyalog]

Dyalog APL on UNIX handles the following signals:

1 SIGHUP Generated when terminals are disconnected
2 SIGINT Weak interrupt
3 SIGQUIT Strong interrupt
15 SIGTERM Termination signal .. the default value to the kill command

Dyalog APL also handles SIGPIPE and SIGUSR1 for internal purposes and talking to APs.

APL checks to see if a SIGQUIT has been caught after "each APL operation". If at least one has, it will generate an event 1003. However, if the end of the current line of APL code is reached rather than another APL operation, then an event 1002 will be generated.

APL checks to see if a SIGINT has been caught at the end of each line of APL code. If at least one has, then an event 1002 will be generated.

If a SIGHUP or SIGTERM is caught, then the input stream is closed immediately, and then an event 1002 is generated at the end of the current line of code. When the interpreter attempts to read input next, an event 1005 (EOF INTERRUPT) is be generated.


Should you need to identify which signal was caught and you are using V12.1 you can use 4007I ⍬.

4007I ⍬ returns a numeric vector. Each element is a count of the number of times the interpreter has received signal X, where X is the 1 origin-based index into the vector.

The counts are reset each time 4007I ⍬ is called.
Many of the counters will be masked, so the count will always be 0.
The length of this vector will be O/S dependent, and potentially version dependent: it is the responsibility of the programmer to allow for the vector being of varying length.

So, for example:

0 2 1 0 0 0 ...

says that since the last time 4007I ⍬ was called the interpreter has caught two signal 2s and one signal 3. Note that due to the way that signal 3s are dealt with by the interpreter, you will most likely always get a 2 and a 3.

The main driver for implementing this I-Beam was to allow the programmer to identify when signal 1 and signal 15s have been received by the interpreter: your code should check 4007I ⍬ whenever an event 1002 or 1003 is trapped by your APL code so that you can take appropriate action depending on what has been received. In particular, when a 1 or 15 has been sent to the interpreter, you should assume that the input stream has already been closed and that you cannot get any further input from the session. This may therefore help to reduce the frequency of having apl processes going into very tight error loops, trying to get input.


Don't forget that it is possible that the somewhere up the stack of shells that you are running signals might have been caught, and sysadmins may have already configured your environment so that some signals are ignored, or others issued in their place.