Programmation Systèmes

Cours 5 — Signals

Stefano Zacchiroli
zack@pps.univ-paris-diderot.fr

Laboratoire PPS, Université Paris Diderot

2013–2014

URL http://upsilon.cc/zack/teaching/1314/progsyst/
Copyright © 2011–2013 Stefano Zacchiroli
License Creative Commons Attribution-ShareAlike 3.0 Unported License
http://creativecommons.org/licenses/by-sa/3.0/

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 1 / 92

Outline

1 Signal concepts

2 Unreliable signals API

3 Reliable signals API

4 Real-time signals

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 2 / 92

Outline

1 Signal concepts

2 Unreliable signals API

3 Reliable signals API

4 Real-time signals

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 3 / 92

Introduction

Definition (Signal)
A signals is a software interrupt. A signal is delivered to processes
as an asynchronous event wrt the usual execution flow.

Signals are used to represent several kinds of events:

events generated by (human) users through the terminal
ñ e.g. Ctrl-C (SIGINT), Ctrl-Z (SIGSTOP), . . .
hardware faults
ñ e.g. divide-by-0, segment violation (SIGSEGV), invalid memory
references (SIGBUS), . . .
anomalous software conditions (software faults)
ñ e.g. writing to a connected IPC facility (SIGPIPE), out of band
data notification (SIGURG), time-based reminders (SIGALRM), . . .
(payload less) process to process signaling via kill(2)
sysadm to process communication via kill(1)

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 4 / 92

Signal processing model

Most of the events a UNIX process deals with are handled according
to the pull model:
when the process is ready/willing to handle an event, it uses
syscalls to check whether an event has occurred in the past and
to retrieve the associated information

Signals are the most prominent example of asynchronous events

under UNIX. They are dealt with according to the push model:1
the process declares its interest in listening for an event (a
signal) by registering an handler that will be called as soon as
the event occurs
the handler is passed all information associated to the signal
normal program execution usually resumes upon handler
termination
1
on Linux there is a desire to support signal management in pull mode, but
nothing concrete exists yet
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 5 / 92
On the (bad) reputation of signals

In the early days of UNIX, the “reputation” of signals was pretty bad,
due to a number of unreliability causes in signal delivery. We refer
to signal implementation and specification of those days as
unreliable signals.2

The bad reputation of those days still affects the usage of signals.

. . . even though modern UNIX-es have a much better handling of

signals, in terms of reliable specifications and implementations, as
well as expressiveness (e.g. POSIX.1-2001 added support for signal
payloads).
We refer to modern signals as reliable signals.

2
we’ll discuss unreliability causes in a bit
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 6 / 92
Signal names
Each signal is identified by a signal name starting with SIG
<signal.h> associates signal names to platform-specific signal
numbers
available signals are standardized by SUS, although some are
XSI extensions; each platform might support additional
implementation-specific signals
signal number 0 corresponds to the null signal, which is no
signal and has special meaning for kill
Available signals on a given platform can be listed with kill(1).
Example (Linux x86 signals)
$ k i l l −l
1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP
6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1
11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM
16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP
21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ
26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR
31) SIGSYS <snip>
$
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 7 / 92
Signal disposition

Each process can express his wishes to the kernel about what should
happen when a specific signal occurs. The signal disposition (or
action) is one of the following:

1 ignore the signal: nothings happens, the event is ignored

2 catch the signal: a process-specific handler is executed when
the event corresponding to the signal occurs
3 default: every signal is associated to a default action, which is
one of:
ñ terminate the process (most common)
ñ terminate the process and dump core (for further debugging)
ñ ignore the signal
ñ stop/resume process execution

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 8 / 92

Signal handler execution
Main program

start of program

flowof execution
Kernel calls signal
handler on behalf Signal handler
Delivery of process
of signal 2
3
1 instruction m Code of
instruction m+1 signal handler
4 is executed
Program
resumes at return
point of interruption
exit()

TLPI, Figure 20-1

Beware: signal handler invocation might interrupt the program at

any time (!) — instructions in the picture are more fine-grained than
your C statements. . .
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 9 / 92
Signal life cycle

1 A signal is generated for a process (or sent to a process) when

the corresponding event occurs.
2 The signal remain pending between generation and delivery.
3 A process has the option to block signal delivery.
ñ each process is associated to a set of signals, called signal mask,
that the process is currently blocking
ñ if a blocked signal is generated and its disposition is either
default or catch, the signal remains pending until either of:
a. the process unblocks the signal
b. the process changes signal disposition to ignore the signal

4 A signal is delivered to a process when the action specified by

the signal disposition of the receiving process has been taken.
ñ note: the decision of what to do with a signal is taken when the
signal is delivered, not when it is generated

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 10 / 92

Notable signals

We briefly go through some of the most notable signals.

For a complete list see SUS or the summary table on APUE,
Figure 10.1.
We’ll go through signals according to the following ad-hoc
classification:
process-related events
job control
terminal events
hardware faults
software faults
custom events
run-time signals

For each signal we mention its number on the Linux x86 platform.

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 11 / 92

Notable signals — process-related events
The following signals are used to notify of the occurrence of
process-related notifications:
Self notifications
SIGABRT (6, default: terminate+core) generated by calling the
abort function
SIGALRM (14, default: terminate) generated at the expiration of a
timer set by the alarm function
Other notifications
SIGCHLD (17, default: ignore) sent to the parent process upon
the termination of a child
typical usage: collect termination status with wait
SIGURG (23, default: ignore) notification of some “urgent
condition”
use case: notification of the arrival of out of band
data on some input channel
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 12 / 92
Notable signals — job control
Various signals are delivered to processes for purposes related to
UNIX job control:

SIGSTOP (19, default: stop process) sent to a process to suspend

its execution
cannot be ignored or caught
SIGCONT (18, default: resume the process if it was stopped;
ignore otherwise) sent to a process just after it resume
execution
use case: redraw terminal upon restart
SIGTERM (15, default: terminate process) sent to a process to ask
for its termination
it’s the signal sent by kill(1) by default
SIGKILL (9, default: terminate process) sent to kill a process
cannot be ignored or caught

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 13 / 92

Notable signals — terminal events

Many signals can be generated by the terminal driver during

interactive usage of the shell:

SIGHUP (1, default: terminate, mnemonic: Hang UP) sent to

session leader process when the controlling terminal is
disconnected
typical (ab)use: ask daemon processes to reread
configuration, based on the observation that
daemons do not have a controlling terminal
SIGINT (2, default: terminate) terminal character to request
termination of all foreground processes
usual keyboard shortcut: Ctrl-C
SIGQUIT (3, default: terminate+core) same as SIGINT, but
additionally request to dump core
usual keyboard shortcut: Ctrl-\

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 14 / 92

Notable signals — terminal events (cont.)

SIGTSTP (20, default: stop process, mnemonic: Terminal SToP)

interactive stop signal, used to request top of all
foreground processes
usual keyboard shortcut: Ctrl-Z
SIGTTIN (21, default: stop process, mnemonic: Terminal Try
INput) sent to a background process if it attempts to
read from its controlling terminal
SIGTTOU (22, default: stop process, mnemonic: Terminal Try
OUtput) dual to SIGTTIN, sent to a background process
if it attempts to write to its controlling terminal
SIGWINCH (28, default: ignore; warning: non-SUS, but supported
by most UNIX-es) sent to all foreground processes upon
change of the window size associated to the terminal
use case: redraw the screen
e.g. top
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 14 / 92
Notable signals — hardware faults
Some signals are related to (perceived) hardware faults:
SIGBUS (7, default: terminate+core) sent to a process that
causes a bus error, e.g.:
unaligned memory access
access to a non-existent memory address
real hardware failure when accessing memory
SIGSEGV (11, default: terminate+core) sent to a process that
causes a SEGmentation Violation (or segmentation
fault), i.e. an attempt to access a memory location it has
no right to access
SIGFPE (8, default: terminate+core) invalid arithmetic/floating
point operation
e.g. divide by 0
SIGILL (4, default: terminate+core) sent to a process that
attempt to execute an illegal instruction
e.g. malformed assembly instruction
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 15 / 92
Notable signals — software faults

Some signals are used to notify of software-related faults:

SIGPIPE (13, default: terminate) sent to a process if it attempts
to write to a connected process-to-process IPC facility
that has no connected readers
e.g. pipe, socket

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 16 / 92

Notable signals — custom events

Two signals are reserved for custom, application-defined use:

SIGUSR1 (10, default: terminate)

SIGUSR2 (12, default: terminate)
both signals have no specific meaning other than the handling
semantics that custom signal handlers might assign to it

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 17 / 92

Notable signals — real-time signals
Recent POSIX.1 updates have introduced many APIs for real-time
purposes. They include handling of real-time signals.
Real-time signals also introduce a new range of signals. Instead of
being a set of signal names, all signals between SIGRTMIN and
SIGRTMAX are real-time signals.
real-time signals can be used as regular signals (and vice-versa)
but, as we’ll see, their delivery semantics is different
Example (Linux x86 real-time signals)
$ k i l l −l
<snip > 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2
37) SIGRTMIN+3 38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6
41) SIGRTMIN+7 42) SIGRTMIN+8 43) SIGRTMIN+9 44) SIGRTMIN+10
45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13 48) SIGRTMIN+14
49) SIGRTMIN+15 50) SIGRTMAX−14 51) SIGRTMAX−13 52) SIGRTMAX−12
53) SIGRTMAX−11 54) SIGRTMAX−10 55) SIGRTMAX−9 56) SIGRTMAX−8
57) SIGRTMAX−7 58) SIGRTMAX−6 59) SIGRTMAX−5 60) SIGRTMAX−4
61) SIGRTMAX−3 62) SIGRTMAX−2 63) SIGRTMAX−1 64) SIGRTMAX
$

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 18 / 92

Interlude — core dump

Definition (core dump)

A core dump (or core file) is an image of the memory of a process,
taken at crash-time of the corresponding process.

Useful information to debug the crash is stored in core files:

memory dump at the time of crash
termination status (usually abnormal)
copies of processor registries

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 19 / 92

Interlude — core dump (cont.)

The default disposition of many signals includes code dumps.

Nonetheless we rarely see core files around. Why?

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 20 / 92

Interlude — core dump (cont.)

The default disposition of many signals includes code dumps.

Many default setups set to 0 the maximum size limit on core
dumps.
Such a limit can be inspected and changed with ulimit.

Example (fiddling with core file size limit)

$ help u l i m i t learn how to use ulimit

<snip >

$ u l i m i t −c
0 core file generation is disabled

$ u l i m i t −c unlimited enable core file generation, no size limit

$ u l i m i t −c
unlimited

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 20 / 92

Interlude — core dump example

#include < s t d l i b . h>

#include <unistd . h>

i n t main ( void ) {
sleep ( 6 0 ) ;
e x i t ( EXIT_SUCCESS ) ;
}

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 21 / 92

Interlude — core dump example (cont.)

$ gcc −Wall −g −o sleep sleep . c

$ . / sleep
Ctrl-C SIGINT, default disposition: terminate (no core)
^C
$ l s −l core
l s : cannot access core : No such f i l e or d i r e c t o r y
$ . / sleep
Ctrl-\ SIGQUIT, default disposition: terminate+core
^\Quit
$ l s −l core
l s : cannot access core : No such f i l e or d i r e c t o r y
$ u l i m i t −c unlimited
$ . / sleep
Ctrl-\ SIGQUIT again
^\Quit ( core dumped)
$ l s −l core
−rw−−−−−−− 1 zack zack 237568 o t t 19 15:44 core
$ du core
100
$

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 22 / 92

Interlude — core dump example (cont.)

$ gdb sleep core

<snip>
Core was generated by ‘ . / sleep ’ .
Program terminated with s i g n a l 3 , Quit .
#0 0x00007f0b7c7731b0 in nanosleep ( ) from / l i b /x86_64−linux−gnu/ l i b c . so .6
( gdb )

( gdb ) bt
#0 0x00007f0b7c7731b0 in nanosleep ( ) from / l i b /x86_64−linux−gnu/ l i b c . so .6
#1 0x00007f0b7c773040 in sleep ( ) from / l i b /x86_64−linux−gnu/ l i b c . so .6
#2 0x0000000000400542 in main ( ) at sleep . c :5
( gdb )
$

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 23 / 92

Outline

1 Signal concepts

2 Unreliable signals API

3 Reliable signals API

4 Real-time signals

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 24 / 92

signal

The main activity related to signal management is changing signal

dispositions for a given process.
The signal function is the simplest interface to that activity.

#include <signal.h>
void (*signal(int signo, void (*handler)(int)))(int)
Returns: previous signal disposition if OK, SIG_ERR on error

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 25 / 92

signal (cont.)

The main activity related to signal management is changing signal

dispositions for a given process.
The signal function is the simplest interface to that activity.

#include <signal.h>
void (*signal(int signo, void (*handler)(int)))(int)
Returns: previous signal disposition if OK, SIG_ERR on error

It can be made easier to the eyes by applying appropriate typedef

substitutions:

typedef void (*sighandler_t)(int);

sighandler_t signal(int signo, sighandler_t handler);
Returns: previous signal disposition if OK, SIG_ERR on error

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 25 / 92

signal (cont.)

typedef void (*sighandler_t)(int);

sighandler_t signal(int signo, sighandler_t handler);
Returns: previous signal disposition if OK, SIG_ERR on error

signo is the name (or number) of the signal whose disposition

we want to change
handler is one of:
SIG_IGN to request ignoring of signo
SIG_DFL to reset signal disposition of signo to the default
pointer to the handler—a function accepting a int
parameter and returning void—that will be invoked
to complete signal delivery passing the number of
the signal being delivered
signal returns SIG_ERR if the request fails; (a pointer to) the
previous signal disposition if it succeeds
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 25 / 92
signal — example
#include <stdio . h>
#include < s t d l i b . h>
#include <unistd . h>
#include <s i g n a l . h>
#include " helpers . h "

/ * one handler for both s i g n a l s * /

s t a t i c void sig_usr ( i n t signo ) {
i f ( signo == SIGUSR1 )
p r i n t f ( " received SIGUSR1\n " ) ;
else i f ( signo == SIGUSR2 )
p r i n t f ( " received SIGUSR2\n " ) ;
}
i n t main ( void ) {
i f ( s i g n a l ( SIGUSR1 , sig_usr ) == SIG_ERR )
err_sys ( " can ’ t catch SIGUSR1 " ) ;
i f ( s i g n a l ( SIGUSR2 , sig_usr ) == SIG_ERR )
err_sys ( " can ’ t catch SIGUSR2 " ) ;
for ( ; ; )
sleep ( 6 0 ) ;
} / * based on APUE , Figure 10.2 * /
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 26 / 92
signal — example (cont.)

Demo

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 27 / 92

signal inheritance

Upon fork
child inherits parent’s signal disposition
ñ ignored and default signals remain the same in child
ñ caught signals will continue to be caught by the same handlers

Upon exec

can we do the same?

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 28 / 92

signal inheritance

Upon fork
child inherits parent’s signal disposition
ñ ignored and default signals remain the same in child
ñ caught signals will continue to be caught by the same handlers

Upon exec

while ignore and default dispositions could remain the same, catch
dispositions could not: function pointers would be meaningless in
the address space of a new (different) program

exec resets to the default actions all catch disposition

whereas ignore and default dispositions are inherited by the
new program

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 28 / 92

Sending signals

Signals can be sent to arbitrary processes using kill3 and to the

current process using raise:

#include <signal.h>
int kill (pid_t pid, int signo);
int raise(int signo);
Returns: 0 if OK, -1 on error

The meaning of pid depends on its value:

pid > 0 signal sent to process with PID pid
pid == 0 signal sent to all processes in the same process group
of the sender
pid < 0 signal sent to all processes of process group abs(pid)
pid == −1 signal sent to all processes

3
historic misnomer
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 29 / 92
Sending signals — permissions

As signal can have important consequences (e.g. program

termination, but also polluting the file system with core dumps),
appropriate permissions are required to send a signal.

General kill permission rules

a superuser process can kill arbitrary processes
a normal user process can kill processes whose real or saved
set-user-ID are equal to the sender process real or effective uid

Notes:
permission to kill a specific process can be checked by
kill-ing with the null signal
group kill-ing sends signals only to processes allowed by
permissions (without failing)

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 30 / 92

pause

pause blocks a process until a signal is caught (i.e. activating a

signal handler):

#include <unistd.h>
int pause(void);
Returns: -1 with errno set to EINTR

note: ignored signals do not trigger pause return

remember: delivered != sent

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 31 / 92

alarm

#include <unistd.h>
unsigned int alarm(unsigned int seconds);
Returns: 0 or n. of seconds until previously set alarm

Using alarm, a process can set a timer that will expire seconds
seconds in the future. After timer expiration, the signal SIGALRM will
be sent to the calling process.
Note: default action for SIGALRM is process termination.

There is only one timer per process.

alarm(0) cancels the timer
the n. of seconds left before previous timer expiration is
returned at each invocation

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 32 / 92

alarm — example
#include <stdio . h>
#include < s t d l i b . h>
#include <unistd . h>
#include <time . h>
#include <s i g n a l . h>
#include " helpers . h "

void c l o c k _ t i c k ( i n t signo ) {
p r i n t f ( " \ r%ld " , time ( NULL ) ) ; / * overwrite prev . time with new * /
alarm ( 1 ) ; / * re−set alarm * /
}

i n t main ( void ) { / * a ( UNIX time ) clock * /

setvbuf ( stdout , NULL , _IONBF , BUFSIZ ) ; / * avoid buffering * /
p r i n t f ( " \e [2 J \e [H" ) ; / * home and clear screen w/ ANSI ESC seqs * /

i f ( s i g n a l ( SIGALRM , c l o c k _ t i c k ) == SIG_ERR )
err_sys ( " can ’ t catch SIGALRM " ) ;
c l o c k _ t i c k ( −1); / * p r i n t current time * /
alarm ( 1 ) ;
for ( ; ; ) / * wait / catch loop * /
pause ( ) ;
e x i t ( EXIT_SUCCESS ) ;
} / * clock . c * /
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 33 / 92
alarm — example (cont.)

Demo

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 34 / 92

sleep

sleep—which we have used often—is a timeout-powered version of

pause:4

#include <unistd.h>
unsigned int sleep(unsigned int seconds);
Returns: 0 or number of unslept seconds

The calling process will suspend until either:

1 the given number of seconds elapses, or
2 a signal is caught by the process and its signal handler returns
ñ the return value tells us the remaining time, in seconds, until
termination condition (1)

4
depending on whether sleep is implemented using alarm or not, there might
be nasty interactions among the two. . .
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 35 / 92
Unreliable-signal semantics

In early UNIX-es, signal were unreliable and hard to control:

1 signals could get lost and never be delivered to target processes
2 there was no way for a process to temporarily block a signal:
ñ either the process catches a signal (accepting the possibility of
being interrupted at any time),
ñ or the process ignores it (losing the possibility of ever knowing
that someone send him a signal while he was ignoring it)

Even if implementations of modern UNIX-es are past these issues, by

using the unreliable signal API there is no way of knowing for sure
that these issues are gone.
Whether it is the case or not is implementation-dependent.

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 36 / 92

Unreliability I — reset to default

Action dispositions used to be reset to the default action at each

delivery. Code like the following was (and still is) common place:
/ * signal handler * /
void my_handler ( i n t signo ) {
s i g n a l ( SIGINT , my_handler ) ; / * re−e s t a b l i s h handler * /
... / * process s ig nal * /
}

i n t main ( void ) {
...
s i g n a l ( SIGINT , my_handler ) ; / * e s t a b l i s h handler * /
...
}

what’s wrong with this code?

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 37 / 92

Unreliability I — reset to default

Action dispositions used to be reset to the default action at each

delivery. Code like the following was (and still is) common place:
/ * signal handler * /
void my_handler ( i n t signo ) {
s i g n a l ( SIGINT , my_handler ) ; / * re−e s t a b l i s h handler * /
... / * process s ig nal * /
}

i n t main ( void ) {
...
s i g n a l ( SIGINT , my_handler ) ; / * e s t a b l i s h handler * /
...
}
problem: there is race condition between the start of handler
execution and the re-establishment of the signal handler
a signal delivered in between will trigger default action
ñ potentially terminating the process

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 37 / 92

Unreliability II — snoozing signals

Context: alternate program phases where we can’t be interrupted

(“critical regions”), with phases where we can, without losing
relevant signals delivered during critical regions
Building block: wait for a signal to occur, then proceed

Let’s try with a global flag:

i n t s i g _ i n t _ f l a g = 0; / * global f l a g * /
void my_handler ( i n t signo ) {
s i g n a l ( SIGINT , my_handler ) ;
s i g _ i n t _ f l a g = 1; / * caught signal , set f l a g * /
}
i n t main ( void ) {
...
s i g n a l ( SIGINT , my_handler ) ; / * e s t a b l i s h handler * /
...
while ( s i g _ i n t _ f l a g == 0)
pause ( ) ; / * wait for signal * /
... / * caught signal , proceed * /
}
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 38 / 92
Unreliability II — snoozing signals (cont.)
code idea:
1 let’s wait for a signal
2 when the signal handler returns the program will be awakened
(thanks to pause) and the flag will tell us if a specific handler
has been executed
3 if the signal is not relevant, go to (1)

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 39 / 92

Unreliability II — snoozing signals (cont.)
code idea:
1 let’s wait for a signal
2 when the signal handler returns the program will be awakened
(thanks to pause) and the flag will tell us if a specific handler
has been executed
3 if the signal is not relevant, go to (1)

problem: race condition between the test sig_int_flag == 0

and pause
if a signal gets delivered in that window (and if it’s delivered
only once): the program will block forever because nobody will
(re)check the flag before blocking (forever)
problem mitigation: using sleep instead of pause
ñ it induces timeout and/or polling problems, depending on sleep
argument

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 39 / 92

Interrupted system calls

System calls invocations can be (intuitively) classified in two classes:

1 “slow” invocations that might block indefinitely, e.g.:

ñ read, write, and ioctl when called on “slow” devices that

could in turn block indefinitely (e.g. terminal, pipe, socket)
« note: disk I/O fails the above definition
ñ blocking open (e.g. on a FIFO)
ñ wait and friends
ñ socket interfaces
ñ file locking interfaces
ñ IPC synchronization primitives (message queues, semaphores,
Linux futexes, etc.)
2 “fast” invocations: every other invocation

If a signal gets caught during a slow syscall invocation, the syscall

might—after execution of the handler—return an error and set
errno to EINTR.
In early UNIX-es that was the only possible behavior.
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 40 / 92
Interrupted system calls (cont.)
The pro of interrupt-able system calls is that they allow to have a
way out of situations that could block forever.
e.g. blocking reads from a terminal with an away user
The cons of interrupt-able system calls is that the code needs to deal
with the EINTR error condition explicitly and restart the interrupted
syscall invocation with code like:
while ( ( n = read ( fd , buf , BUFFSIZE ) ) != 0) {
i f ( n == −1) {
i f ( errno == EINTR )
continue ;
else
// handle other error cases
}
// handle success cases
}
// handle end of f i l e

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 41 / 92

Unreliability III — EINTR uncertainty

Some of the early UNIX-es (most notably BSDs) introduced automatic

restart of the system calls: ioctl, read, readv, writev, wait,
waitpid.

The drawback of automatic restart is obvious: it throws away the

advantages of interrupt-able syscalls.

POSIX.1 allows implementations to restart system calls but do not

require it:

Using the unreliable signal API there is no way of knowing whether

slow syscall invocations will be restarted or not.

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 42 / 92

Unreliability IV — signal queuing

What happens if the same signal is generated twice, before the

target process has a chance to deliver it?

POSIX.1 allows for two possibilities:

signal queuing the kernel keeps track of the number of signals
generated and performs an equal number of deliveries
note: (non real-time) signals are indistinguishable
from one another; therefore the order is irrelevant
no signal queuing the kernel only keeps a bitmask of pending
signals and performs a single delivery

Using the unreliable signal API there is no way of being sure if

queuing is in effect or not.

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 43 / 92

Unreliability IV — signal queuing example
#include <unistd . h>
#include <s i g n a l . h>
#include " helpers . h "

void sig_usr ( i n t signo ) {

p r i n t f ( " caught s i g n a l %d\n " , signo ) ; }
i n t main ( void ) {
s i g s e t _ t newmask, oldmask ;
i f ( ( s i g n a l ( SIGUSR1 , sig_usr ) == SIG_ERR )
| | s i g n a l ( SIGUSR2 , sig_usr ) == SIG_ERR )
err_sys ( " s i g n a l e rro r " ) ;
sigemptyset (&newmask ) ;
sigaddset (&newmask, SIGUSR1 ) ; sigaddset (&newmask, SIGUSR2 ) ;
i f ( sigprocmask ( SIG_BLOCK , &newmask, &oldmask ) < 0) / * block SIGUSR *
err_sys ( " SIG_BLOCK e rro r " ) ;
sleep ( 1 0 ) ; / * SIGUSR * here w i l l remain pending * /
i f ( sigprocmask ( SIG_SETMASK , &oldmask , NULL ) < 0) / * unblocks SIGUSR
err_sys ( " sigprocmask e rro r " ) ;
i f ( s i g n a l ( SIGUSR1 , SIG_DFL ) == SIG_ERR ) err_sys ( " s i g n a l e rro r " ) ;
i f ( s i g n a l ( SIGUSR2 , SIG_DFL ) == SIG_ERR ) err_sys ( " s i g n a l e rro r " ) ;
p r i n t f ( " SIGUSR * unblocked\n " ) ;
while ( 1 ) pause ( ) ;
e x i t ( EXIT_SUCCESS ) ;
} / * no−queue . c * /
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 44 / 92
Unreliability IV — signal queuing example (cont.)

Demo

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 44 / 92

Unreliability V — causality

Whereas homonymous signals are indistinguishable, different

signals are.

Let’s assume different signals are generated for the same target
process p in the order s1 , . . . sn .
What would be the delivery order of signals to p?

For regular signals POSIX.1 gives no guarantee about the

preservation of any order between generation and delivery.

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 45 / 92

Unreliability V — causality example
#include <unistd . h>
#include <s i g n a l . h>
#include " helpers . h "

void sig_usr ( i n t signo ) {

p r i n t f ( " caught s i g n a l %d\n " , signo ) ; }
i n t main ( void ) {
s i g s e t _ t newmask, oldmask ;
i f ( ( s i g n a l ( SIGUSR1 , sig_usr ) == SIG_ERR )
| | s i g n a l ( SIGUSR2 , sig_usr ) == SIG_ERR )
err_sys ( " s i g n a l e rro r " ) ;
sigemptyset (&newmask ) ;
sigaddset (&newmask, SIGUSR1 ) ; sigaddset (&newmask, SIGUSR2 ) ;
i f ( sigprocmask ( SIG_BLOCK , &newmask, &oldmask ) < 0) / * block SIGUSR *
err_sys ( " SIG_BLOCK e rro r " ) ;
sleep ( 1 0 ) ; / * SIGUSR * here w i l l remain pending * /
i f ( sigprocmask ( SIG_SETMASK , &oldmask , NULL ) < 0) / * unblocks SIGUSR
err_sys ( " sigprocmask e rro r " ) ;
i f ( s i g n a l ( SIGUSR1 , SIG_DFL ) == SIG_ERR ) err_sys ( " s i g n a l e rro r " ) ;
i f ( s i g n a l ( SIGUSR2 , SIG_DFL ) == SIG_ERR ) err_sys ( " s i g n a l e rro r " ) ;
p r i n t f ( " SIGUSR * unblocked\n " ) ;
while ( 1 ) pause ( ) ;
e x i t ( EXIT_SUCCESS ) ;
} / * no−queue . c * /
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 46 / 92
Unreliability V — causality example

Demo

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 46 / 92

Signal handler vs static memory

Unrelated to the unreliability of the old API, another reliability

concern should be taken into account when programming signals:

we don’t know what the process was doing when the signal was
delivered
What if the process:
1 was in the middle of malloc or free?

2 was in the middle of a function that uses static memory to

return a value?

What if we call the same function in the signal handler?

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 47 / 92

Signal handler vs static memory

Unrelated to the unreliability of the old API, another reliability

concern should be taken into account when programming signals:

we don’t know what the process was doing when the signal was
delivered
What if the process:
1 was in the middle of malloc or free?

ñ malloc maintains a linked list of allocated blocks and might be

in the process of updating it. . .
2 was in the middle of a function that uses static memory to
return a value?
ñ the return value of the first call will be overwritten by the return
value of the handler call. . .
What if we call the same function in the signal handler?

FAIL.
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 47 / 92
Reentrant functions

In general, we cannot exclude that the program was doing anything

like the previous examples at signal delivery time.
Therefore, the only safeguard is avoid using the same functionalities
from signal handlers.

The functions that can safely be invoked from signal handlers are
called reentrant functions (or async-safe functions). The full list is
prescribed by POSIX.

Note: functions of the standard I/O library are not reentrant, due to
the usage of global data structures (e.g. buffers).

Yes, we’ve been lazy and used printf within signal handlers.
You can’t.

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 48 / 92

The big list of reentrant functions

accept access aio_error aio_return aio_suspend alarm bind

cfgetispeed cfgetospeed cfsetispeed cfsetospeed chdir chmod
chown clock_gettime close connect creat dup dup2 execle execve
_Exit _exit fchmod fchown fcntl fdatasync fork fpathconf fstat
fsync ftruncate getegid geteuid getgid getgroups getpeername
getpgrp getpid getppid getsockname getsockopt getuid kill link
listen lseek lstat mkdir mkfifo open pathconf pause pipe poll
posix_trace_event pselect raise read readlink recv recvfrom
recvmsg rename rmdir select sem_post send sendmsg sendto
setgid setpgid setsid setsockopt setuid shutdown sigaction
sigaddset sigdelset sigemptyset sigfillset sigismember signal
sigpause sigpending sigprocmask sigqueue sigset sigsuspend
sleep socket socketpair stat symlink sysconf tcdrain tcflow
tcflush tcgetattr tcgetpgrp tcsendbreak tcsetattr tcsetpgrp time
timer_getoverrun timer_gettime timer_settime times umask uname
unlink utime wait waitpid write

— reference: SUS; APUE, Chapter 10

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 49 / 92

Outline

1 Signal concepts

2 Unreliable signals API

3 Reliable signals API

4 Real-time signals

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 50 / 92

Signal sets

Several features of the reliable signal API manipulate sets of signals.

e.g. a process willing to block a set of signals
e.g. retrieving the current set of pending signals

The first (trivial) part of the reliable signals API is used to manipulate
sets of signals and offers basic set operations.
The data type sigset_t is defined by POSIX.1 to represent a signal
set.

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 51 / 92

sigset_t manipulation

POSIX.1 functions

#include <signal.h>
int sigemptyset(sigset_t *set);
int sigfillset (sigset_t *set);
int sigaddset(sigset_t *set, int signo);
int sigdelset(sigset_t *set, int signo);
Returns: 0 if OK, -1 on error

#include <signal.h>
int sigismember(const sigset_t *set, int signo);
Returns: 1 if true, 0 if false, -1 on error

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 52 / 92

sigset_t manipulation (cont.)

Glibc functions (only if _GNU_SOURCE is defined)

#define _GNU_SOURCE
#include <signal.h>
int sigisemptyset(sigset_t *set);
Returns: 1 if set contains no signals, 0 otherwise

#define _GNU_SOURCE
#include <signal.h>
int sigorset(sigset_t *dest, sigset_t *left, sigset_t *right);
int sigandset(sigset_t *dest, sigset_t *left, sigset_t *right);
Returns: 0 if OK, -1 on error

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 52 / 92

sigset_t manipulation (cont.)

Let S be the set of all available signals, S, S1 , S2 sets of signals being

manipulated, and n ∈ S a specific signal.

The following straightforward analogies with set operations hold:

sisget_t set operation

sigemptyset(S) S←∅
sigfillset(S) S←S
sigaddset(S, n) S ← S ∪ {n}
sigdelset(S, n) S ← S \ {n}
sigorset(S, S1 , S2 ) S ← S1 ∪ S2
sigandset(S, S1 , S2 ) S ← S1 ∩ S2
sigismember(S, n) n∈S
sigisemptyset(S) S=∅

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 52 / 92

Signal masks

Definition (Signal mask)

A signal mask is a set of signals that are currently blocked from
delivery to a process.

Every UNIX process is associated to a signal mask.

Using the sigprocmask syscall a process can:
1 retrieve the signal mask
2 change the signal mask
3 do both (1) and (2) in a single atomic action

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 53 / 92

sigprocmask

#include <signal.h>
int sigprocmask(int how, const sigset_t *restrict set, sigset_t *restrict oset);
Returns: 0 if OK, -1 on error

Retrieving the signal mask

if oset is non-NULL, it will be filled with the current signal mask
Changing the signal mask
if set is non-NULL, the current signal mask M will be changed
according to the value of how:
how effect
SIG_BLOCK M ← M ∪ set
SIG_UNBLOCK M ← M \ set
SIG_SETMASK M ← set
before sigprocmask returns, at least one of the unblocked and
pending signals (if any) get delivered
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 54 / 92
sigpending

Reminder: blocked signals are raised but not delivered.

During the interim, signals are pending and can be retrieved by the
target process using:

#include <signal.h>
int sigpending(sigset_t *set);
Returns: 0 if OK, -1 on error

The interface is the same of sigprocmask’s oset parameter:

sigpending’s set will be filled with the set of currently pending
signals.

sigpending does not change the set of pending signals.

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 55 / 92

sigprocmask & sigpending — example
#include <stdio . h>
#include < s t d l i b . h>
#include <unistd . h>
#include <s i g n a l . h>
#include " helpers . h "

void s i g _ q u i t ( i n t signo ) {
p r i n t f ( " caught SIGQUIT\n " ) ;
i f ( s i g n a l ( SIGQUIT , SIG_DFL ) == SIG_ERR )
err_sys ( " can ’ t reset SIGQUIT " ) ;
}
i n t main ( void ) {
s i g s e t _ t newmask, oldmask , pendmask ;
i f ( s i g n a l ( SIGQUIT , s i g _ q u i t ) == SIG_ERR )
err_sys ( " can ’ t catch SIGQUIT " ) ;

sigemptyset (&newmask ) ;
sigaddset (&newmask, SIGQUIT ) ; / * block SIGQUIT * /
i f ( sigprocmask ( SIG_BLOCK , &newmask, &oldmask ) < 0)
err_sys ( " SIG_BLOCK e r r o r " ) ;
sleep ( 5 ) ; / * SIGQUIT here w i l l remain pending * /
i f ( sigpending (&pendmask ) < 0)
err_sys ( " sigpending e r r o r " ) ;
i f ( sigismember(&pendmask, SIGQUIT ) )
p r i n t f ( " \nSIGQUIT pending\n " ) ;

/ * Reset signal mask which unblocks SIGQUIT * /

i f ( sigprocmask ( SIG_SETMASK , &oldmask , NULL ) < 0)
err_sys ( " SIG_SETMASK e r r o r " ) ;
p r i n t f ( " SIGQUIT unblocked\n " ) ;
sleep ( 5 ) ; / * SIGQUIT here w i l l core dump * /
e x i t ( EXIT_SUCCESS ) ;
}
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 56 / 92
sigprocmask & sigpending — example (cont.)

Demo

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 56 / 92

sigprocmask & sigpending — example (cont.)

Demo

the pending signal is indeed delivered before sigprocmask

returns
we use SIG_SETMASK on the old mask to unblock instead of
SIG_UNBLOCK and SIGQUIT
ñ in this example the difference is irrelevant, but it does matter
when interacting with other code, if we want to be modular wrt
signal handling

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 56 / 92

Welcome, sigaction!

The main ingredient of the reliable signal API is sigaction, used to

modify and/or inspect signal dispositions.

sigaction completely subsumes signal and extends it with

several extra features:
expressive signal handlers, which get passed information about
the signal raise (and delivery) context
the ability to block signals during handler execution
control over restart (EINTR) behavior

sigaction, not signal, should be used in all new code that deals
with signals.

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 57 / 92

sigaction

Let’s look at sigaction prototype:

#include <signal.h>
int sigaction(int signo, const struct sigaction *restrict act,
struct sigaction *restrict oact);
Returns: 0 if OK, -1 on error

signo is the signal whose disposition we want to act upon

act, if non-NULL, is the new signal disposition we want to set for
signo
oact, if non-NULL, is where we want the current signal
disposition (before change, if any) to be put

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 58 / 92

struct sigaction
The sigaction struct encodes signal dispositions:

struct s i g a c t i o n {
void ( * sa_handler ) ( i n t ) ; / * old−s t y l e handler * /
s i g s e t _ t sa_mask ; / * extra si g n a l s to block * /
int sa_flags ; / * signal options * /
/ * alternate , new−s t y l e handler * /
void ( * sa_sigaction ) ( int , s i g i n f o _ t * , void * ) ;
}

The handler can be specified in two alternative ways:

1 by default, sa_handler is used as in signal

2 if sa_flags contains the SA_SIGINFO flag, sa_sigaction is

used instead.

Example of how to increase prototype expressivity, without giving

up backward compatibility.
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 59 / 92
struct sigaction (cont.)

When using sa_sigaction, signal handlers will be invoked via a

richer prototype:
void handler ( i n t signo , s i g i n f o _ t * info , void * context ) ;

signo is as before;
info is a rich structure giving information about the event that
caused the signal;
context can be cast to a ucontext_t structure that identifies
the context of the process at signal delivery time
ñ see getcontext (2)

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 60 / 92

struct siginfo_t — example
As an example, here is a typical siginfo_t on Linux x86:
typedef struct s i g i n f o _ t {
i n t si_signo ; /* signal number * /
i n t si_errno ; /* errno value * /
i n t si_code ; /* signal code ( depend on s ign al ) * /
pid_t s i _ p i d ; /* sending process ’ s PID * /
uid_t s i _ u i d ; /* sending process ’ s real UID * /
int si_status ; /* e x i t value or signa l * /
c l o c k _ t si_utime ; /* user time consumed * /
c l o c k _ t si_stime ; /* system time consumed * /
s i g v a l _ t si _va lue ; /* signal payload value * /
int s i _ i n t ; /* POSIX .1b signal * /
void * s i _ p t r ; /* POSIX .1b signal * /
void * si_addr ; /* memory l o c a t i o n that caused f a u l t * /
i n t si_band ; /* band event * /
int si_fd ; /* f i l e descriptor * /
}
Note that POSIX.1 only mandates si_signo and si_code.
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 61 / 92
struct siginfo_t — use cases

for SIGCHLD, si_pid, si_status, si_uid, si_utime, and

si_stime will be set, easing collecting termination information
from children
for SIGILL, SIGSEGV, SIGBUS, SIGFPE, and SIGTRAP si_addr
contains the address responsible for the fault, easing debugging
if a signal is generated by some error condition, si_errno
contains the corresponding errno, easing error recovery
...

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 62 / 92

The wonderful world of si_code (cit.)
si_code deserves special mention as it explains how (for
user-generated signals) or why (for kernel-generated signals) the
signal has been sent. Admissible values of si_code depend on the
signal. Some examples:
Signal si_code Reason
Any SI_USER signal sent by kill
SI_ASYNCIO completion of async I/O request
SI_MESGQ message arrival on a message queue
SIGCHLD CLD_EXITED child has exited
CLD_KILLED termination (no core)
CLD_STOPPED child has stopped
SIGSEGV SEGV_MAPERR address not mapped
SEGV_ACCERR invalid permission
SIGFPE FPE_INTDIV division by zero
FPE_INTOVF integer overflow
... ... ...
By inspecting si_code we can discriminate among very precise
signal causes, and hence piggyback more logic into signal handlers.
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 63 / 92
More on sigaction — persistence

A signal disposition installed with sigaction is granted by POSIX.1

to persist across signal delivery.

The need of code like the following is gone! (and the behavior is no
longer implementation-dependent)
/ * signal handler * /
void my_handler ( i n t signo ) {
s i g n a l ( SIGINT , my_handler ) ; / * re−e s t a b l i s h handler * /
... / * process sign al * /
}

i n t main ( void ) {
...
s i g n a l ( SIGINT , my_handler ) ; / * e s t a b l i s h handler * /
...
}

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 64 / 92

More on sigaction — signal masks

sigaction guarantees that during signal handler execution a

temporary signal mask is in effect.
the kernel guarantees that the temporary mask is in effect only
during signal handler execution and that the original mask will
be restored as soon as the handler returns

The temporary signal mask composition is as follows:

the signal being handled, signo, is included by default in the
temporary signal mask
addition signals are passed using the sigset_t sa_mask field
of struct sigaction

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 65 / 92

More on sigaction — options
sa_flags field of struct sigaction allows for further control of
sigaction behavior. It is the bitwise OR of 0 (no options), 1, or
more of a set of flags that includes:

SA_NODEFER do not include signo in temporary mask by default

SA_NOCLDWAIT automatic child reaping, for SIGCHLD
SA_ONSTACK request signal handling on an alternate stack
SA_RESTART request automatic restart of syscalls interrupted by
signo
SA_RESETHAND request one-shot mode, reset disposition of signo
after delivery
SA_SIGINFO use sa_sigaction (already seen)

With sa_flags we can obtain back behaviors of unreliable signals

on demand (but why???).

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 66 / 92

sigaction — example
#include <unistd . h>
#include <s i g n a l . h>
#include " helpers . h "

#define SIG_WHY ( i ) ( ( i )−>si_code==SI_USER ? " ( k i l l ) " : " " )

void sig_dispatch ( i n t signo , s i g i n f o _ t * info , void * c t x t ) {

i f ( info −>si_signo == SIGUSR1 )
p r i n t f ( " received SIGUSR1 %s\n " , SIG_WHY ( i n f o ) ) ;
else i f ( info −>si_signo == SIGSEGV )
p r i n t f ( " received SIGSEGV %s\n " , SIG_WHY ( i n f o ) ) ;
}
i n t main ( void ) {
struct s i g a c t i o n act ;
sigemptyset (& act . sa_mask ) ;
act . sa_flags = SA_SIGINFO ;
act . sa_sigaction = sig_dispatch ;

i f ( s i g a c t i o n ( SIGUSR1 , &act , NULL ) == −1)

err_sys ( " can ’ t catch SIGUSR1 " ) ;
i f ( s i g a c t i o n ( SIGSEGV , &act , NULL ) == −1)
err_sys ( " can ’ t catch SIGSEGV " ) ;
for ( ; ; )
sleep ( 6 0 ) ;
} /* sigaction . c */
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 67 / 92
sigaction — example (cont.)

Demo

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 67 / 92

A (reliable) implementation of signal

#include <s i g n a l . h>

sighandler_t s i g n a l ( i n t signo , sighandler_t func ) {

struct s i g a c t i o n act , oact ;

act . sa_handler = func ;

sigemptyset (& act . sa_mask ) ;
act . s a _ f l a g s = 0;
i f ( signo != SIGALRM ) { / * or not . . . * /
#ifdef SA_RESTART
act . s a _ f l a g s | = SA_RESTART ;
#endif
}
i f ( s i g a c t i o n ( signo , &act , &oact ) < 0)
return ( SIG_ERR ) ;
return ( oact . sa_handler ) ;
}

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 68 / 92

Snoozing signals — redux
with sigprocmask we can avoid signal interference within
critical code region
if the signal is raised while blocked, it will be delivered as soon
as we unblock it
how can we explicitly wait for a signal, no matter if it happens while
blocked or after?
sigemptyset (&newmask ) ;
sigaddset (&newmask, SIGINT ) ;
i f ( sigprocmask ( SIG_BLOCK , &newmask, &oldmask ) < 0)
err_sys ( " SIG_BLOCK e r r o r " ) ;

/ * c r i t i c a l region * /

i f ( sigprocmask ( SIG_SETMASK , &oldmask , NULL ) < 0)

err_sys ( " SIG_SETMASK e r r o r " ) ;

/ * signal window open again * /

pause ( ) ; / * wait for si gna l * /

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 69 / 92

sigsuspend
We’re back at square one: if the signal is raised either while blocked,
or shortly after unblocking and before pause, it will be lost and the
process might block forever (race condition!).
The solution is a system call to atomically reset the signal mask and
put the process to sleep. Enter sigsuspend:

#include <signal.h>
int sigsuspend(const sigset_t *sigmask);
Returns: -1 with errno set to EINTR

set the signal mask to sigmask and put the process into sleep
sigsuspend will return after the handler of a caught signal
returns
ñ note: always return a EINTR failure
the signal mask is returned to its previous value before
returning
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 70 / 92
Helper — pr_mask
#include <errno . h>
#include <s i g n a l . h>

void pr_mask ( const char * l a b e l ) {

s i g s e t _ t sigs ;
i n t errno_save ;

errno_save = errno ;
i f ( sigprocmask ( 0 , NULL , &sigs ) < 0)
err_sys ( " sigprocmask e r r o r " ) ;

p r i n t f ( "%s : " , l a b e l ) ;
i f ( sigismember(& sigs , SIGINT ) ) p r i n t f ( " SIGINT " ) ;
i f ( sigismember(& sigs , SIGQUIT ) ) p r i n t f ( " SIGQUIT " ) ;
i f ( sigismember(& sigs , SIGUSR1 ) ) p r i n t f ( " SIGUSR1 " ) ;
i f ( sigismember(& sigs , SIGUSR2 ) ) p r i n t f ( " SIGUSR2 " ) ;
i f ( sigismember(& sigs , SIGALRM ) ) p r i n t f ( " SIGALRM " ) ;
/ * etc . . . * /
p r i n t f ( " \n " ) ;
errno = errno_save ;
}
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 71 / 92
sigsuspend — example
#include <stdio . h>
#include < s t d l i b . h>
#include <s i g n a l . h>
#include " helpers . h "

void s i g _ i n t ( i n t signo ) {
pr_mask ( " \ nin s i g _ i n t " ) ;
}
i n t main ( void ) {
s i g s e t _ t newmask, oldmask , waitmask ;

pr_mask ( " program s t a r t " ) ;

i f ( s i g n a l ( SIGINT , s i g _ i n t ) == SIG_ERR ) err_sys ( " s i g n a l ( SIGINT ) er ror " ) ;
sigemptyset (&waitmask ) ;
sigaddset (&waitmask , SIGUSR1 ) ;
sigemptyset (&newmask ) ;
sigaddset (&newmask, SIGINT ) ;

i f ( sigprocmask ( SIG_BLOCK , &newmask, &oldmask ) < 0)

err_sys ( " SIG_BLOCK e r r o r " ) ;
pr_mask ( "< c r i t i c a l region >" ) ;
sleep ( 4 ) ;
pr_mask ( " </ c r i t i c a l region >" ) ;

i f ( sigsuspend (&waitmask ) != −1) err_sys ( " sigsuspend e r r o r " ) ;

pr_mask ( " a f t e r return from sigsuspend " ) ;

/ * Reset signal mask which unblocks SIGINT . * /

i f ( sigprocmask ( SIG_SETMASK , &oldmask , NULL ) < 0)
err_sys ( " SIG_SETMASK e r r o r " ) ;
pr_mask ( " done " ) ;
e x i t ( EXIT_SUCCESS ) ;
} / * sigsuspend . c * /
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 72 / 92
sigsuspend — example (cont.)

$ . / sigsuspend
program s t a r t :
< c r i t i c a l region >: SIGINT
^C
</ c r i t i c a l region >: SIGINT

in s i g _ i n t : SIGINT SIGUSR1
a f t e r return from sigsuspend : SIGINT
done :
$

after sigsuspend returns the signal mask is back to its previous

value
why is SIGINT blocked inside sig_int?
we block SIGUSR1 only to show that the temporary mask set by
sigsuspend is in effect

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 73 / 92

sigsuspend — critical region loop
#include " helpers . h "
i n t q u i t f l a g = 0; / * global f l a g * /
void s i g _ i n t ( i n t signo ) {
i f ( signo == SIGINT ) p r i n t f ( " \ ninterrupt \n " ) ;
else i f ( signo == SIGQUIT ) q u i t f l a g = 1;
}
i n t main ( void ) {
sigset_t newmask, oldmask , zeromask ;
i f ( s i g n a l ( SIGINT , s i g _ i n t ) == SIG_ERR
| | s i g n a l ( SIGQUIT , s i g _ i n t ) == SIG_ERR )
err_sys ( " s i g n a l ( ) e rro r " ) ;
sigemptyset (&zeromask ) ;
sigemptyset (&newmask ) ;
sigaddset (&newmask, SIGQUIT ) ;
i f ( sigprocmask ( SIG_BLOCK , &newmask, &oldmask ) < 0)
err_sys ( " SIG_BLOCK e rro r " ) ;
while ( q u i t f l a g == 0)
/ * can do c r i t i c a l region work here * /
sigsuspend (&zeromask ) ;
/ * SIGQUIT got caught * /
i f ( sigprocmask ( SIG_SETMASK , &oldmask , NULL ) < 0)
err_sys ( " SIG_SETMASK e rro r " ) ;
e x i t ( EXIT_SUCCESS ) ;
} / * sigsuspend2 . c * /
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 74 / 92
sigsuspend — critical region loop (cont.)

$ . / sigsuspend2
^C
interrupt
^C
interrupt
^C
interrupt
^\
$

The example shows the typical. . .

critical region design pattern for signals

1 block undesired signals by default
2 loop
a. critical region work
b. sigsuspend with old, more liberal mask to handle accumulated
signals

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 75 / 92

Reminder — parent/child synchronization

We need synchronization primitives that processes can use to

synchronize and avoid race conditions.

As a proof of concept we will consider the following primitives:5

WAIT_PARENT child blocks waiting for (a “signal” from) parent
WAIT_CHILD parent blocks waiting for (a “signal” from) children
TELL_PARENT(pid) child “signals” parent
TELL_CHILD(pid) parent “signals” child

5
we’ll also have TELL_WAIT in both processes, for initialization
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 76 / 92
Reminder — TELL/WAIT intended usage

i n t main ( void ) {
pid_t pid ;

TELL_WAIT();

i f ( ( pid = fork ( ) ) < 0) err_sys ( " fork e r r o r " ) ;

else i f ( pid == 0) {
WAIT_PARENT(); / * parent f i r s t * /
charatatime ( " output from c h i l d \n " ) ;
} else {
charatatime ( " output from parent \n " ) ;
TELL_CHILD(pid);
}
e x i t ( EXIT_SUCCESS ) ;
}

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 77 / 92

Signal-based TELL/WAIT
We can now give an implementation of TELL/WAIT, based on
(reliable) signals:
s t a t i c i n t s i g f l a g ; / * s et nonzero by s i g handler * /
s t a t i c s i g s e t _ t newmask, oldmask , zeromask ;
s t a t i c void sig_usr ( i n t signo ) { / * w i l l catch SIGUSR { 1 , 2 } * /
s i g f l a g = 1;
}
void TELL_WAIT ( void ) {
i f ( s i g n a l ( SIGUSR1 , sig_usr ) == SIG_ERR )
err_sys ( " s i g n a l ( SIGUSR1 ) e r r o r " ) ;
i f ( s i g n a l ( SIGUSR2 , sig_usr ) == SIG_ERR )
err_sys ( " s i g n a l ( SIGUSR2 ) e r r o r " ) ;
sigemptyset (&zeromask ) ;
sigemptyset (&newmask ) ;
sigaddset (&newmask, SIGUSR1 ) ;
sigaddset (&newmask, SIGUSR2 ) ;
/ * Block SIGUSR1 and SIGUSR2 * /
i f ( sigprocmask ( SIG_BLOCK , &newmask, &oldmask ) < 0)
err_sys ( " SIG_BLOCK e r r o r " ) ;
}
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 78 / 92
Signal-based TELL/WAIT (cont.)

void TELL_PARENT ( pid_t pid ) {

k i l l ( pid , SIGUSR2 ) ; / * t e l l parent we ’ re done * /
}

void WAIT_PARENT ( void ) {

while ( s i g f l a g == 0)
sigsuspend (&zeromask ) ; / * wait for parent * /
s i g f l a g = 0;

/ * Reset s ig na l mask to o r i g i n a l value . * /

i f ( sigprocmask ( SIG_SETMASK , &oldmask , NULL ) < 0)
err_sys ( " SIG_SETMASK e r r o r " ) ;
}

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 79 / 92

Signal-based TELL/WAIT (cont.)

void TELL_CHILD ( pid_t pid ) {

k i l l ( pid , SIGUSR1 ) ; / * t e l l c h i l d we ’ re done * /
}

void WAIT_CHILD ( void ) {

while ( s i g f l a g == 0)
sigsuspend (&zeromask ) ; / * wait for c h i l d * /
s i g f l a g = 0;

/ * Reset s ig na l mask to o r i g i n a l value . * /

i f ( sigprocmask ( SIG_SETMASK , &oldmask , NULL ) < 0)
err_sys ( " SIG_SETMASK e r r o r " ) ;
}

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 80 / 92

system vs signals

We’ve already given an implementation of system based on fork,

exec, and wait. What would happen to system in a signal setting?

In particular:
1 what if the process calling system is catching SIGCHLD?

2 what if the user hits Ctrl-C while system’s child is running?

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 81 / 92

system vs signals

We’ve already given an implementation of system based on fork,

exec, and wait. What would happen to system in a signal setting?

In particular:
1 what if the process calling system is catching SIGCHLD?

ñ the process is probably doing so to be notified of termination of

his own children, not of system’s specific children
2 what if the user hits Ctrl-C while system’s child is running?
ñ signals are delivered to all foreground processes in the terminal

A proper system implementation should shield the caller from

delivery of signals that are specific to system’s child.
More generally, you should think at which signals to mask in the
parent when fork-ing.

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 81 / 92

Signal-aware system implementation
#include <sys / wait . h>
#include <errno . h>
#include <s i g n a l . h>
#include <unistd . h>

i n t system ( const char * cmdstring ) {

pid_t pid ;
i n t status ;
struct s i g a c t i o n ignore , saveintr , savequit ;
s i g s e t _ t chldmask , savemask ;

i f ( cmdstring == NULL ) return ( 1 ) ;

ignore . sa_handler = SIG_IGN ; / * ignore SIGINT and SIGQUIT * /

sigemptyset (& ignore . sa_mask ) ;
ignore . sa_flags = 0;
i f ( s i g a c t i o n ( SIGINT , &ignore , &s a v e i n t r ) < 0)
return ( −1);
i f ( s i g a c t i o n ( SIGQUIT , &ignore , &savequit ) < 0)
return ( −1);
sigemptyset (&chldmask ) ; / * now block SIGCHLD * /
sigaddset (&chldmask , SIGCHLD ) ;
i f ( sigprocmask ( SIG_BLOCK , &chldmask , &savemask ) < 0)
return ( −1);
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 82 / 92
Signal-aware system implementation (cont.)
i f ( ( pid = fork ( ) ) < 0) {
status = −1; / * probably out of processes * /
} else i f ( pid == 0) { /* c h i l d */
/ * restore previous signal actions & reset signal mask * /
s i g a c t i o n ( SIGINT , &saveintr , NULL ) ;
s i g a c t i o n ( SIGQUIT , &savequit , NULL ) ;
sigprocmask ( SIG_SETMASK , &savemask , NULL ) ;
execl ( " / bin /sh " , " sh " , "−c " , cmdstring , ( char * ) 0 ) ;
_exit (127); / * exec error * /
} else { / * parent * /
while ( waitpid ( pid , &status , 0) < 0)
i f ( errno != EINTR ) {
status = −1; / * error other than EINTR from waitpid ( ) * /
break ;
}
} / * now restore previous signal actions & reset signal mask * /
i f ( s i g a c t i o n ( SIGINT , &saveintr , NULL ) < 0)
return ( −1);
i f ( s i g a c t i o n ( SIGQUIT , &savequit , NULL ) < 0)
return ( −1);
i f ( sigprocmask ( SIG_SETMASK , &savemask , NULL ) < 0)
return ( −1);
return ( status ) ;
} // APUE , Figure 10.28
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 82 / 92
Outline

1 Signal concepts

2 Unreliable signals API

3 Reliable signals API

4 Real-time signals

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 83 / 92

Real-time signals

We have seen that real-time signals are the subset of available

signals comprised in between RTMIN and RTMAX.

Their delivery semantics differs substantially from that of ordinary

signals:
1 real-time signals are granted to be queued

ñ i.e. for each raise of a real-time signal there will be a

corresponding delivery
2 real-time signals are delivered according to their priority
(ordered from RTMIN to RTMAX)
3 real-time signals can carry payloads

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 84 / 92

Signal queuing example — redux
#include <stdio . h>
#include < s t d l i b . h>
#include <unistd . h>
#include <s i g n a l . h>
#include " helpers . h "

void s i g _ r t ( i n t signo ) {
p r i n t f ( " caught s i g n a l %d\n " , signo ) ;
}

i n t main ( void ) {
s i g s e t _ t newmask, oldmask ;

i f ( s i g n a l ( SIGRTMIN , s i g _ r t ) == SIG_ERR
| | s i g n a l ( SIGRTMIN+1, s i g _ r t ) == SIG_ERR )
err_sys ( " s i g n a l e r r o r " ) ;
sigemptyset (&newmask ) ;
sigaddset (&newmask, SIGRTMIN ) ;
sigaddset (&newmask, SIGRTMIN +1);
i f ( sigprocmask ( SIG_BLOCK , &newmask, &oldmask ) < 0) / * block SIGRT * * /
err_sys ( " SIG_BLOCK e r r o r " ) ;
sleep ( 5 ) ;
i f ( sigprocmask ( SIG_SETMASK , &oldmask , NULL ) < 0) / * unblocks SIGRT * * /
err_sys ( " sigprocmask e r r o r " ) ;
i f ( s i g n a l ( SIGRTMIN , SIG_DFL ) == SIG_ERR ) err_sys ( " s i g n a l er ror " ) ;
i f ( s i g n a l ( SIGRTMIN+1, SIG_DFL ) == SIG_ERR ) err_sys ( " s i g n a l er ror " ) ;
p r i n t f ( " SIGRT * unblocked\n " ) ;
while ( 1 ) {
sleep ( 5 ) ;
}
e x i t ( EXIT_SUCCESS ) ;
} / * queue . c * /

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 85 / 92

Signal queuing example — redux

Demo

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 85 / 92

siqgueue

The interface for sending signals with payloads is provided by:

#include <signal.h>
int sigqueue(pid_t pid, int sig, const union sigval value);
Returns: 0 if OK, -1 on error

The first two arguments are as in kill. The 3rd argument allow to
send signals with payloads that can be either integers or pointers:
union s i g v a l {
int sival_int ;
void * s i v a l _ p t r ;
}

Target process can retrieve the payload via the si_value field of
struct siginfo_t (only for sigaction new style handlers).

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 86 / 92

siqgueue — example

With sigqueue, signals can be used as very expressive

communication mechanisms (although not necessarily handy. . . ).

As an extreme example, we show how to transfer a file across

processes using signal payloads and relying on real-time signal
queuing.

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 87 / 92

siqgueue — example (cont.)
#include <s i g n a l . h>
#include <stdio . h>
#include < s t d l i b . h>
#include " helpers . h "

i n t main ( i n t argc , char ** argv ) {

i n t pid , c ;
union s i g v a l v a l ;
i f ( argc < 2) {
p r i n t f ( " Usage : sigqueue−send PID \n " ) ;
e x i t ( EXIT_FAILURE ) ;
}
pid = a t o i ( argv [ 1 ] ) ;
while ( ( c = getchar ( ) ) != EOF ) {
val . s i v a l _ i n t = c ;
i f ( sigqueue ( pid , SIGRTMIN , v a l ) < 0)
err_sys ( " sigqueue e r r o r " ) ;
}
e x i t ( EXIT_SUCCESS ) ;
} / * sigqueue−send . c * /
Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 88 / 92
siqgueue — example (cont.)
#include <s i g n a l . h>
#include <stdio . h>
#include < s t d l i b . h>
#include <unistd . h>
#include " helpers . h "

void receive_char ( i n t signo , s i g i n f o _ t * info , void * c t x t ) {

i f ( putchar ( info −>s i _ v a l u e . s i v a l _ i n t ) == EOF )
err_sys ( " putchar e rro r " ) ;
f f l u s h ( stdout ) ;
}

i n t main ( void ) { / * sigqueue−recv * /

struct s i g a c t i o n act ;
sigemptyset (& act . sa_mask ) ;
act . sa_flags = SA_SIGINFO ;
act . sa_sigaction = receive_char ;
i f ( s i g a c t i o n ( SIGRTMIN , &act , NULL ) == −1)
err_sys ( " s i g a c t i o n e rro r " ) ;
for ( ; ; )
pause ( ) ;
e x i t ( EXIT_SUCCESS ) ;
} / * sigqueue−recv . c * /

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 89 / 92

siqgueue — example (cont.)

$ . / sigqueue−recv &
[ 1 ] 11546
$ . / sigqueue−send 11546 < / etc / issue
Debian GNU/ Linux wheezy/ sid \n \ l
$

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 90 / 92

Signal (un)reliability

We have improved over most of the causes of signal unreliability:

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 91 / 92

Signal (un)reliability

We have improved over most of the causes of signal unreliability:

Unreliability I — reset to default

ñ sigaction

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 91 / 92

Signal (un)reliability

We have improved over most of the causes of signal unreliability:

Unreliability I — reset to default

ñ sigaction
Unreliability II — snoozing signals
ñ sigaction (for signal handlers)
ñ sigprocmask + sigsuspend (for arbitrary critical regions)

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 91 / 92

Signal (un)reliability

We have improved over most of the causes of signal unreliability:

Unreliability I — reset to default

ñ sigaction
Unreliability II — snoozing signals
ñ sigaction (for signal handlers)
ñ sigprocmask + sigsuspend (for arbitrary critical regions)
Unreliability III — EINTR uncertainty
ñ sigaction + SA_RESTART

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 91 / 92

Signal (un)reliability

We have improved over most of the causes of signal unreliability:

Unreliability I — reset to default

ñ sigaction
Unreliability II — snoozing signals
ñ sigaction (for signal handlers)
ñ sigprocmask + sigsuspend (for arbitrary critical regions)
Unreliability III — EINTR uncertainty
ñ sigaction + SA_RESTART
Unreliability IV — signal queuing
ñ sigqueue + real-time signals

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 91 / 92

Signal (un)reliability

We have improved over most of the causes of signal unreliability:

Unreliability I — reset to default

ñ sigaction
Unreliability II — snoozing signals
ñ sigaction (for signal handlers)
ñ sigprocmask + sigsuspend (for arbitrary critical regions)
Unreliability III — EINTR uncertainty
ñ sigaction + SA_RESTART
Unreliability IV — signal queuing
ñ sigqueue + real-time signals
Unreliability V — causality
ñ real-time signal priorities (only partially addressed)

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 91 / 92

Signal reliability on Linux

the Linux kernel version of signal provides System V semantics

(i.e. signal disposition reset by default, no signal blocking
during handler execution)
starting from version 2 of glibc (i.e. all GNU libc6 and above),
the signal wrapper does not call kernel’s signal but uses
sigaction, offering reliable semantics
the default behavior with respect to EINTR is a bit complicated,
but well documented in signal(7). The main principles are:
ñ common I/O syscalls respect the presence (or absence) of
SA_RESTART (read/write, open, wait, socket interfaces, flock,
etc.)
ñ syscalls where interruptions are part of their semantics ignore
SA_RESTART, are always interrupted (pause/sigsuspend/sleep,
timeout-powered socket interfaces, select/poll, etc.)

Stefano Zacchiroli (Paris Diderot) Signals 2013–2014 92 / 92