There are two varieties of signals available, named and anonymous.
A named signal is one for which we have a symbolic name, such as
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 symbol) -> signal or #f
(integer->signal integer) -> signal
(signal? x) -> boolean
(signal-name signal) -> symbol or #f
(signal-os-number signal) -> integer
(signal=? signal0 signal1) -> boolean
Name->signalreturns a (named) signal or
#fif the the signal
nameis not supported by the operating system. The signal returned by
integer->signalis a named signal if
integercorresponds to a named signal in the current operating system; otherwise it returns an anonymous signal.
Signal-namereturns a symbol if
signalis named and
#fif it is anonymous.
signal1have the same operating system number and
#fif they do not.
abort - abnormal termination (as by abort())
alarm - timeout signal (as by alarm())
floating point exception
hangup - hangup on controlling terminal or death of controlling process
interrupt - interaction attention
kill - termination signal, cannot be caught or ignored
pipe - write on a pipe with no readers
quit - interaction termination
segmentation violation - invalid memory reference
termination - termination signal
user1 - for use by applications
user2 - for use by applications
child - child process stopped or terminated
continue - continue if stopped
stop - cannot be caught or ignored
read from control terminal attempted by background process
write to control terminal attempted by background process
bus error - access to undefined portion of memory
trace or breakpoint trap
IOT trap - a synonym for ABRT
bad argument to routine (SVID)
stack fault on coprocessor
urgent condition on socket (4.2 BSD)
I/O now possible (4.2 BSD)
A synonym for SIGIO (System V)
A synonym for SIGCHLD
CPU time limit exceeded (4.2 BSD)
File size limit exceeded (4.2 BSD)
Virtual alarm clock (4.2 BSD)
Profile alarm clock
Power failure (System V)
A synonym for SIGPWR
File lock lost
Window resize signal (4.3 BSD, Sun)
signalto the process corresponding to
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 signals) -> signal-queue
(signal-queue? x) -> boolean
(signal-queue-monitored-signals signal-queue) -> list of signals
(dequeue-signal! signal-queue) -> signal
(maybe-dequeue-signal! queue-queue) -> signal or #f
Make-signal-queuereturns a new signal-queue that will monitor the signals in the list
Signal-queue?is a predicate for signal queues.
Signal-queue-monitored-signalsreturns a list of the signals currently monitored by
maybe-dequeue-signalboth return the next received-but-unread signal from
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
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))))
maybe-dequeue-signal!will only return signals that are currently on the signal-queue's list of signals.
Previous: Process primitives | Next: Process environment