Skip to content
The Signal Belfry

/static/campanario/en/conceito/

Menu

The concept, on a single page

From teletype to belfry

Where signals come from, why so many names look like fossils, and what a bell tower has to do with the kernel.

Signals are Unix's oldest interprocess communication mechanism: asynchronous, payload-free, a number and nothing more. They were born at Bell Labs in the seventies, when the terminal was a teletype hanging on a phone line — and the vocabulary stuck: SIGHUP is, literally, the hung-up telephone.

This collection's metaphor: the kernel is the belfry over the city of processes. Every bell has its ring with an agreed meaning — some announce (a child has finished, the window changed), some alarm (the program faults), and one of them brings down the tower without the process even hearing it.

What a process can do with a ring

Three things: hang a handler on it (give the ring its own meaning), block the signal (cover its ears for a while — the ring waits in line) or ignore it altogether. The exceptions are SIGKILL and SIGSTOP, which ring not for the process but for the kernel: they cannot be caught, blocked or ignored.

When a fatal signal ends a process, the shell records the death in the exit status: 128 plus the bell's number. 130 is Ctrl+C; 137, the bullet of kill -9.

The numbers vary; the names don't

kill -9 and kill -15 became folklore, but the numbers change from architecture to architecture — SIGUSR1 is 10 on x86-64 and 30 on SPARC. The numbers quoted on this collection's labels are Linux on x86-64, per signal(7); in scripts, call the bells by name.

Why lots of little pages

For the same reason as the herbarium and the reliquary: every bell, every drawer, every ordering and this very text are separate HTML files, linked together, written by a generator a few hundred lines long. State becomes an address; the browser handles the rest.