La liste des signaux possibles est dépendante de la machine
et est obtenue par la commande kill -l
.
Attention, pour certains shells la commande kill
est
interne et ne donne pas le même résultat que la commande de l'OS.
Un handler est exécuté à la réception d'un signal par
un processus.
Le handler peut être changé, en respectant certaines contraientes
(e.g. les signaux KILL
et STOP
ne peuvent
avoir de signal handler).
En l'absence de handler, le comportement par défaut est ignore
ou die.
Dans un premier temps on fera
un court programme perl
qui définit
un signal handler pour chaque signal, qui affiche le nom du signal reçu
et on testera ce programme en lui envoyant des signaux avec
la commande kill
.
Utiliser man perlipc
.
Ensuite, on fera la même chose en C,
en choisissant l'approche utilisant la fonction
signal
ou celle utilisant la fonction sigaction
.
On réfléchira à ce qu'il est autorisé de faire dans un handler.
On pourra aussi regarder la sortie de stty -a
pour
voir quelles combinaisons de touches du clavier servent à envoyer
les signaux INT, QUIT et STOP (attention, zsh les remet aux valeurs
par défaut à chaque affichage de prompt).
On cherche à établir un protocole de communication entre deux
processus A et B (lancés par un fork
) par des signaux.
SIGUSR1
et SIGUSR2
.
Résoudre le problème en utilisant
un protocole dans lequel B émet un accusé
de réception à chaque signal.
Faire le programme en Perl.
[corrigé]
Résoudre le problème en utilisant la possibilité des OS modernes de bloquer l'arrivée de signaux.
Une telle recherche est assez longue. On cherche à pouvoir la lancer en arrière plan, tout en pouvant continuer à dialoguer avec le processus. On cherche essentiellement à lui transmettre plusieurs messages différents:
STATUS
),
RESTART
),
STOP
),
DISP n
).
SIGUSR1
et SIGUSR2
,
et faire une application Perl qui envoie ce type de message
à un processus donné.