signal

SIGNAL(2)                 Manuel du programmeur Linux                SIGNAL(2)



NOM
       signal - Gestion de signaux ANSI C

SYNOPSIS
       #include <signal.h>

       typedef void (*sighandler_t)(int);

       sighandler_t signal(int signum, sighandler_t handler);

DESCRIPTION
       Le comportement de signal() varie selon les versions d'UNIX, et a aussi
       varié au cours du temps dans les différentes versions de Linux.
       Ãvitez de l'utiliser : utilisez plutôt sigaction(2). Consultez la
       section Portabilité plus bas.

       signal() installe le gestionnaire handler pour le signal signum.
       handler peut être SIG_IGN, SIG_DFL ou l'adresse d'une fonction
       définie par le programmeur (un « gestionnaire de signal »).

       Lors de l'arrivée d'un signal correspondant au numéro signum, l'un
       des événements suivants se produit :

       *  Si le gestionnaire vaut SIG_IGN, le signal est ignoré.

       *  Si le gestionnaire est SIG_DFL, l'action par défaut associée à ce
          signal est entreprise (consultez signal(7)).

       *  Si le gestionnaire est une fonction, alors tout d'abord le
          gestionnaire est reconfiguré à  SIG_DFL, ou le signal est bloqué
          (voir la section Portabilité ci‐dessous), puis handler est appelée
          avec l'argument signum. Si l'invocation du gestionnaire a bloqué le
          signal, le signal est débloqué au retour du gestionnaire.

       Les signaux SIGKILL et SIGSTOP ne peuvent être ni ignorés, ni
       interceptés.

VALEUR RENVOYÃE
       signal() renvoie la valeur précédente du gestionnaire de signaux, ou
       SIG_ERR en cas d'erreur. En cas d'erreur, errno contient le code
       d'erreur.

ERREURS
       EINVAL signum est invalide.

CONFORMITÃ
       C89, C99, POSIX.1-2001.

NOTES
       Les effets de signal() dans un processus multithreadé sont
       indéterminés.

       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(2) ou raise(3). La
       division entière par zéro a un résultat indéfini, sur certaines
       architectures elle déclenche un signal SIGFPE. De même, diviser
       l'entier le plus négatif par -1 peut déclencher SIGFPE.

       Consultez sigaction(2) pour des détails sur ce qui se passe quand on
       place SIGCHLD Ã  SIG_IGN.

       Consultez signal(7) pour une liste de fonctions sûres pour les signaux
       asynchrones qui peuvent être appelées dans les gestionnaires de
       signaux.

       L'utilisation du type sighandler_t est une extension GNU, exposée si
       _GNU_SOURCE est définie. La glibc définit aussi sig_t (dérivé de
       BSD) si _GNU_SOURCE est définie. Sans cette définition de ce type, la
       déclaration de signal() est plus difficile à lire :

           void ( *signal(int signum, void (*handler)(int)) ) (int);

   Portabilité
       La seule utilisation portable de signal() est de de configurer le
       gestionnaire du signal à SIG_DFL ou SIG_IGN. La sémantique associée
       à l'utilisation de signal() pour définir un gestionnaire de signal
       dépend suivant les systèmes (et POSIX.1 autorise explicitement ces
       écarts) ; ne l'utiliser pas pour cela.

       POSIX.1 a résolu ce problème de portabilité est spécifiant
       sigaction(2), qui fournit un contrôle explicite de la sémantique
       quand un gestionnaire de signal est appelé ; utilisez cette interface
       plutôt que signal().

       Dans les systèmes UNIX d'origine, quand un gestionnaire défini par
       signal() était appelé lors de la distribution d'un signal, le
       gestionnaire du signal était remis à SIG_DFL, et le système ne
       bloquait pas la distribution des instances suivantes du signal. Cela
       revenait à appeler sigaction(2) avec les attribut suivants :

           sa.sa_flags = SA_RESETHAND | SA_NODEFER;

       System V fournit également cette sémantique pour signal(). Cela
       posait problème parce qu'un signal pouvait être distribué avant que
       le gestionnaire ait le temps de se réactiver. De plus, la distribution
       rapide d'un même signal pouvait causer des appels récursif au
       gestionnaire.

       BSD a amélioré la situation, mais a malheureusement également
       modifié la sémantique de l'interface de signal() en procédant de
       cette façon. Sous BSD, lorsqu'un gestionnaire de signal est appelé,
       la disposition du signal n'est pas réinitialisée, et les instances
       suivantes du signal ne peuvent être distribuées tant que le
       gestionnaire s'exécute. En outre, certains appels système bloquants
       sont automatiquement relancés s'ils sont interrompus par le
       gestionnaire de signal (consultez signal(7)). La sémantique BSD est
       équivalente à un appel de sigaction(2) avec les attributs suivants :

           sa.sa_flags = SA_RESTART;

       La situation sous Linux est la suivante :

       * L'appel système signal() du noyau fournit la sémantique System V.

       * Par défaut, dans la glibc 2 et les suivantes, la fonction de
         bibliothèque signal() n'appelle pas l'appel système. à la place,
         elle appelle sigaction(2) est fournissant un attribut qui fournit la
         sémantique BSD. Ce comportement par défaut est fourni tant que la
         macro de test de fonctionnalités _BSD_SOURCE est définie. Par
         défaut, _BSD_SOURCE est définie ; elle est également implicitement
         définie si on défini _GNU_SOURCE, et peut également être définie
         explicitement.

         Dans la glibc 2 et les suivantes, si la macro de test de
         fonctionnalités _BSD_SOURCE n'est pas définie, alors signal()
         fourni la sémantique System V. (la définition implicite de
         _BSD_SOURCE par défaut n'est pas fournie si on appelle gcc(1) dans
         un de ses modes demandant le respect d'une norme (-std=xxx ou -ansi)
         ou si on définie certaines autres macro de test de fonctionnalités
         comme _POSIX_SOURCE, _XOPEN_SOURCE ou _SVID_SOURCE ; consultez
         feature_test_macros(7).)

       * La fonction signal() de la libc4 et de la libc5 Linux fournissent la
         sémantique System V. Si on inclue <bsd/signal.h> sur une libc5 au
         lieu de <signal.h>, alors signal() fournie la sémantique BSD.

VOIR AUSSI
       kill(1), alarm(2), kill(2), killpg(2), pause(2), sigaction(2),
       signalfd(2), sigpending(2), sigprocmask(2), sigsuspend(2),
       bsd_signal(3), raise(3), siginterrupt(3), sigqueue(3), sigsetops(3),
       sigvec(3), sysv_signal(3), signal(7)

COLOPHON
       Cette page fait partie de la publication 3.70 du projet man-pages
       Linux. Une description du projet et des instructions pour signaler des
       anomalies peuvent être trouvées à l'adresse
       http://www.kernel.org/doc/man-pages/.

TRADUCTION
       Depuis 2010, cette traduction est maintenue à l'aide de l'outil po4a
       <http://po4a.alioth.debian.org/> par l'équipe de traduction
       francophone au sein du projet perkamon
       <http://perkamon.alioth.debian.org/>.

       Christophe Blaess <http://www.blaess.fr/christophe/> (1996-2003), Alain
       Portal <http://manpagesfr.free.fr/> (2003-2006).  Julien Cristau et
       l'équipe francophone de traduction de Debian (2006-2009).

       Veuillez signaler toute erreur de traduction en écrivant Ã
       <perkamon-fr@traduc.org>.

       Vous pouvez toujours avoir accès à la version anglaise de ce document
       en utilisant la commande « LC_ALL=C man <section> <page_de_man> ».



Linux                            19 avril 2013                       SIGNAL(2)