Scheme 48 Manual | Contents | In Chapter: Access to POSIX
Previous: Signals | Next: Signals

## 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.

- `(signal `signal-name`) -> signal` | syntax

- `(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`

The syntax `signal` returns a (named) signal associated with `signal-name`. `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

- `(signal-process process-id signal)`

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 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-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))))

- `(add-signal-queue-signal! signal-queue signal)`
- `(remove-signal-queue-signal! signal-queue signal)`

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: Signals | Next: Signals