Editer un article - Informaticien.be

Editer un article

Titre
Mots Clés
Texte	[size=18] [b]Nom[/b] [/size] signal - Gestion de signaux ANSI C. [size=18] [b]Résumé[/b] [/size] [b]#include <signal.h>[/b] [b]typedef void (*sighandler_t)(int);[/b] [b][i]sighandler_t signal(int signum , sighandler_t handler );[/i][/b] [size=18] [b]Description[/b] [/size] L'appel-système [b]signal ()[/b] installe un nouveau gestionnaire pour le signal numéro [b]signum .[/b] Le gestionnaire de signal est [i]handler[/i] qui peut être soit une fonction spécifique de l'utilisateur, soit une des constantes [b]SIG_IGN[/b] ou [b]SIG_DFL .[/b] Lors de l'arrivée d'un signal correspondant au numéro [b]signum ,[/b] les événements suivants se produisent : si le gestionnaire correspondant est configuré avec [b]SIG_IGN ,[/b] le signal est ignoré. Si le gestionnaire vaut [b]SIG_DFL ,[/b] l'action par défaut pour le signal est entreprise, comme décrit dans [b]signal (7).[/b] Enfin, si le gestionnaire est dirigé vers une fonction [b]handler (),[/b] alors tout d'abord le gestionnaire est re-configuré à SIG_DFL, ou le signal est bloqué, puis [b]handler ()[/b] est appelé avec l'argument [b]signum .[/b] Utiliser une fonction comme gestionnaire de signal est appelé "intercepter - ou capturer - le signal". Les signaux [b]SIGKILL[/b] et [b]SIGSTOP[/b] ne peuvent ni être ignorés, ni être interceptés. [size=18] [b]Valeur renvoyée[/b] [/size] La fonction [b]signal ()[/b] renvoie la valeur précédente du gestionnaire de signaux, ou [b]SIG_ERR[/b] en cas d'erreur. [size=18] [b]PortabilitÉ[/b] [/size] La fonction [b]signal ()[/b] 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 occurences du signal durant l'appel de la fonction. La bibliothèque GlibC 2 suit ce comportement. Néanmoins, si l'on inclut sur un système sous libc5 [b]<bsd/signal.h>[/b] à la place de [b]<signal.h>[/b] alors [b]signal[/b] est redéfini en tant que [b]__bsd_signal[/b] et disposera alors de la sémantique BSD. C'est peu recommandé. Sur un système fonctionnant avec la GlibC 2, si on définit la constante [b]_XOPEN_SOURCE[/b] ou si on utilise la fonction [b]sysv_signal (),[/b] 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 [b]signal ()[/b] complètement, et utiliser plutôt [b]sigaction (2).[/b] [size=18] [b]Notes[/b] [/size] Comme spécifié par POSIX, le comportement d'un processus est indéfini après la réception d'un signal [b]SIGFPE , [/b] [b]SIGILL , [/b] ou [b]SIGSEGV [/b] qui n'a pas été engendré par une fonction [i]kill()[/i] ou [i]raise()[/i]. La division entière par zéro a un résultat indéfini, sur certaines architecture elle déclenche un signal [b]SIGFPE . [/b] Ignorer ce signal peut conduire à des boucles infinies. De même diviser l'entier le plus négatif par -1 peut déclencher [b]SIGFPE .[/b] D'après POSIX (3.3.1.3) le comportement est indéfini si on positionne [b]SIGCHLD[/b] à [b]SIG_IGN .[/b] Les comportements BSD et SYSV diffèrent, faisant échouer sous Linux les logiciels BSD qui positionne l'action de [b]SIGCHLD[/b] à [b]SIG_IGN .[/b] L'utilisation du type [b]sighandler_t[/b] est une extension GNU. Diverses versions de la bibliothèque C prédéfinissent ce type. Les libc4 et libc5 définissaient [b]SignalHandler ,[/b] GlibC définit [i]sig_t[/i] et, si [b]_GNU_SOURCE[/b] est défini, [i]sighandler_t[/i] également. [size=18] [b]Conformité[/b] [/size] ANSI C [size=18] [b]Voir aussi[/b] [/size] [b]kill (1),[/b] [b]kill (2),[/b] [b]killpg (2),[/b] [b]pause (2),[/b] [b]raise (3),[/b] [b]sigaction (2),[/b] [b]signal (7),[/b] [b]sigsetops (3),[/b] [b]sigvec (2),[/b] [b]alarm (2)[/b] [size=18] [b]Traduction[/b] [/size] Christophe Blaess, 1996-2003.
Fichier