signal − Gestion de signaux ANSI C.

#include <signal.h>

typedef void (*sighandler_t)(int);

sighandler_t signal(int signum, sighandler_t handler);

L’appel système signal() installe un nouveau gestionnaire pour le signal numéro signum. Le gestionnaire de signal est handler qui peut être soit une fonction spécifique de l’utilisateur, soit une des constantes SIG_IGN ou SIG_DFL.

Lors de l’arrivée d’un signal correspondant au numéro signum, les événements suivants se produisent : si le gestionnaire correspondant est configuré avec SIG_IGN, le signal est ignoré. Si le gestionnaire vaut SIG_DFL, l’action par défaut pour le signal est entreprise, comme décrit dans signal(7). Enfin, si le gestionnaire est dirigé vers une fonction handler(), alors tout d’abord le gestionnaire est re-configuré à SIG_DFL, ou le signal est bloqué, puis handler() est appelé avec l’argument signum.

Utiliser une fonction comme gestionnaire de signal est appelé « intercepter - ou capturer - le signal ». Les signaux SIGKILL et SIGSTOP ne peuvent être ni ignorés, ni interceptés.

La fonction signal() renvoie la valeur précédente du gestionnaire de signaux, ou SIG_ERR en cas d’erreur.

La fonction signal() originale d’Unix réinitialisait le gestionnaire à SIG_DFL, comme c’est le cas sous Système V. Linux agissait ainsi avec les bibliothèques libc4 et libc5. Au contraire, BSD ne réinitialise pas le gestionnaire, mais bloque les éventuelles nouvelles occurrences du signal durant l’appel de la fonction. La bibliothèque glibc2 suit ce comportement.

Néanmoins, si l’on inclut sur un système sous libc5 <bsd/signal.h> à la place de <signal.h> alors signal() est redéfini en tant que __bsd_signal et disposera alors de la sémantique BSD. C’est peu recommandé.

Sur un système fonctionnant avec la glibc2, si on définit la constante _XOPEN_SOURCE ou si on utilise la fonction sysv_signal(), on obtient le comportement habituel. C’est peu recommandé.

La modification de la sémantique de l’appel en utilisant une constante symbolique ou un fichier d’en-tête spécial n’est pas une bonne idée. Il vaut mieux éviter d’utiliser signal() complètement, et utiliser plutôt sigaction(2).

Les effets de cet appel dans un processus multi-fils (Ndt : thread) sont indéterminés.

La routine handler doit être très soigneuse car ailleurs, le traitement peut avoir été interrompu à un endroit arbitraire. La spécification POSIX dispose du concept de « fonction sûre ». Si un signal interrompt une fonction non sûre et que handler appelle une fonction non sûre, le comportement est indéterminé. Les fonctions sûres sont explicitement listées dans les diverses normes. La liste de ces fonctions pour POSIX.1-2003 est :

_Exit() _exit() abort() 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() 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().

Comme spécifié par POSIX, le comportement d’un processus est indéfini après la réception d’un signal SIGFPE, SIGILL, ou SIGSEGV qui n’a pas été engendré par une fonction kill() ou raise(). La division entière par zéro a un résultat indéfini, sur certaines architectures elle déclenche un signal SIGFPE. Ignorer ce signal peut conduire à des boucles infinies. De même, diviser l’entier le plus négatif par −1 peut déclencher SIGFPE.

Voir sigaction(2) pour plus de détails lorsque SIGCHLD vaut SIG_IGN.

L’utilisation du type sighandler_t est une extension GNU. Diverses versions de la bibliothèque C prédéfinissent ce type. Les libc4 et libc5 définissaient SignalHandler, glibc définit sig_t et, si _GNU_SOURCE est définie, sighandler_t également.

C89, POSIX.1-2001.

kill(1), alarm(2), kill(2), pause(2), sigaction(2), sigpending(2), sigprocmask(2), sigqueue(2), sigsuspend(2), killpg(3), raise(3), sigsetops(3), sigvec(3), feature_test_macros(7), signal(7)

Ce document est une traduction réalisée par Christophe Blaess <http://www.blaess.fr/christophe/> le 13 octobre 1996 et révisée le 14 août 2006.

L’équipe de traduction a fait le maximum pour réaliser une adaptation française de qualité. La version anglaise la plus à jour de ce document est toujours consultable via la commande : « LANG=C man 2 signal ». N’hésitez pas à signaler à l’auteur ou au traducteur, selon le cas, toute erreur dans cette page de manuel.