xenial (2) signal.2.gz

Provided by: manpages-fr-dev_3.65d1p1-1_all bug

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.65 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 à <debian-l10n-french@lists.debian.org> ou par
       un rapport de bogue sur le paquet manpages-fr.

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