-- Handle signals in forth

Copyright (C) Tektronix, Inc. 1998 - 2001. All rights reserved.

description: The signal-callback system divides signals internally into the following classes:

P4_ON_XXXXX:

a signal which will be assigned a corresponding THROW on forth level, e.g. for SIGFPE

Abort:

a signal that will not kill the current forth process but which has not forth-level THROW either, e.g. SIGILL. It will result in an ABORT" Signal-Description"

Fatal:

the current forth process will die gracefully.

Default:

A signal with some unknown meaning, exported to allow a forth-programmer to hook it anyway, e.g. to let a programmer on AIX to intercept SIGGRANT and run a forth word, otherwise the signal will be left untouched.

Chandled:

A signal used internally be PFE and initially hooked by the runtime system, in general this would be the Job-Control signals and SIGWINCH that will get send when an xterm changes its size.

The first three classes will go to the default Forth Signal-Handler. Its execution will look for user-routine being registered (in which cases that forth-routine will be executed) and otherwise do its default action (to throw, abort" or exit).

The fourth class is not hooked until some user-code requests that signal in which case the user-defiend forth-routine is executed as its action, otherwise the system-defined default-action will be left untouched.

The signal of the fourth type are not handled by the default signal handler defined herein, so can not just call a forth word, if I still get this right ;-)

Dirk-Uwe Zoller

note: forth-level callbacks might not work as expected on all systems that the rest of PFE runs on. Be careful.

Guido Draheim

constructor primitive <<load_signals>>

an executable word (no special usage info)

or wrapper call around p4_load_signals