Scheme 48 Manual | Contents | In Chapter: Access to POSIX
Previous: Process primitives | Next: Process environment

Signals

There are two varieties of signals available, named and anonymous. A named signal is one for which we have a symbolic name, such as kill or pipe. Anonymous signals, for which we only have the current operating system's signal number, have no meaning in other operating systems. Named signals preserve their meaning in image files. Not all named signals are available from all OS's and there may be multiple names for a single OS signal number.

Name->signal returns a (named) signal or #f if the the signal name is not supported by the operating system. The signal returned by integer->signal is a named signal if integer corresponds to a named signal in the current operating system; otherwise it returns an anonymous signal. Signal-name returns a symbol if signal is named and #f if it is anonymous. Signal=? returns #t if signal0 and signal1 have the same operating system number and #f if they do not.

POSIX signals

The following lists the names of the POSIX signals.
abrt abort - abnormal termination (as by abort())
alrm alarm - timeout signal (as by alarm())
fpe floating point exception
hup hangup - hangup on controlling terminal or death of controlling process
ill illegal instruction
int interrupt - interaction attention
kill kill - termination signal, cannot be caught or ignored
pipe pipe - write on a pipe with no readers
quit quit - interaction termination
segv segmentation violation - invalid memory reference
term termination - termination signal
usr1 user1 - for use by applications
usr2 user2 - for use by applications
chld child - child process stopped or terminated
cont continue - continue if stopped
stop stop - cannot be caught or ignored
tstp interactive stop
ttin read from control terminal attempted by background process
ttou write to control terminal attempted by background process
bus bus error - access to undefined portion of memory

Other signals

The following lists the names of the non-POSIX signals that the system is currently aware of.
trap trace or breakpoint trap
iot IOT trap - a synonym for ABRT
emt
sys bad argument to routine (SVID)
stkflt stack fault on coprocessor
urg urgent condition on socket (4.2 BSD)
io I/O now possible (4.2 BSD)
poll A synonym for SIGIO (System V)
cld A synonym for SIGCHLD
xcpu CPU time limit exceeded (4.2 BSD)
xfsz File size limit exceeded (4.2 BSD)
vtalrm Virtual alarm clock (4.2 BSD)
prof Profile alarm clock
pwr Power failure (System V)
info A synonym for SIGPWR
lost File lock lost
winch Window resize signal (4.3 BSD, Sun)
unused Unused signal

Sending signals

Send signal to the process corresponding to process-id.

Receiving signals

Signals received by the Scheme process can be obtained via one or more signal-queues. Each signal queue has a list of monitored signals and a queue of received signals that have yet to be read from the signal-queue. When the Scheme process receives a signal that signal is added to the received-signal queues of all signal-queues which are currently monitoring that particular signal.

Make-signal-queue returns a new signal-queue that will monitor the signals in the list signals. Signal-queue? is a predicate for signal queues. Signal-queue-monitored-signals returns a list of the signals currently monitored by signal-queue. Dequeue-signal! and maybe-dequeue-signal both return the next received-but-unread signal from signal-queue. If signal-queue's queue of signals is empty dequeue-signal! blocks until an appropriate signal is received. Maybe-dequeue-signal! does not block; it returns #f instead.

There is a bug in the current system that causes an erroneous deadlock error if threads are blocked waiting for signals and no other threads are available to run. A work around is to create a thread that sleeps for a long time, which prevents any deadlock errors (including real ones): 

> ,open threads
> (spawn (lambda ()
           ; Sleep for a year
           (sleep (* 1000 60 60 24 365))))
These two procedures can be used to add or remove signals from a signal-queue's list of monitored signals. When a signal is removed from a signal-queue's list of monitored signals any occurances of the signal are removed from that signal-queue's pending signals. In other words, dequeue-signal! and maybe-dequeue-signal! will only return signals that are currently on the signal-queue's list of signals.

Previous: Process primitives | Next: Process environment