J'étais sur le point d'ajouter un gestionnaire de signal supplémentaire à une application que nous avons ici et j'ai remarqué que l'auteur avait utilisé sigaction pour configurer les autres gestionnaires de signal. J'allais utiliser le signal. Pour suivre la convention, je devrais utiliser la sigaction mais si j'écrivais de zéro, que devrais-je choisir?
Réponses
Trop de publicités?
Utiliser sigaction() sauf si vous avez des raisons impérieuses de ne pas le faire.
L' signal() interface a l'antiquité (et donc de disponibilité) en sa faveur, et il est défini dans la norme. Néanmoins, il a un certain nombre de caractéristiques indésirables qu' sigaction() évite, sauf si vous utilisez les drapeaux explicitement ajoutés sigaction() afin de permettre de simuler fidèlement le vieux - signal() comportement.
- L'
signal()fonction ne bloque pas les autres signaux de l'arrivée alors que le gestionnaire est en cours d'exécution;sigaction()peut bloquer d'autres signaux jusqu'à ce que le gestionnaire retourne. - L'
signal()fonction réinitialise le signal d'action de retour à l'SIG_DFL(par défaut) pour presque tous les signaux. Cela signifie que l'signal()gestionnaire devez réinstaller sa première action. Il ouvre également une fenêtre de vulnérabilité entre le temps où le signal est détecté et que le gestionnaire est réinstallé au cours de laquelle si une deuxième instance du signal arrive, le comportement par défaut (généralement de mettre fin, avec parfois des préjugés, aka core dump).
Ce sont généralement de bonnes raisons pour utiliser l' sigaction() au lieu de signal(). Cependant, l'interface de l' sigaction() est indéniablement plus délicat.
Celui des deux que vous utilisez, ne pas être tenté par l'alternative du signal interfaces comme l' sighold(), sigpause(), sigignore() et sigrelse(). Ils sont nominalement alternatives à l' sigaction(), mais ils sont à peine standardisés et sont présents dans POSIX pour la compatibilité ascendante plutôt que pour un usage sérieux. Notez que la norme POSIX dit leur comportement dans les programmes multi-thread n'est pas défini.
(Multi-threaded des programmes et des signaux est une toute autre histoire compliquée. Autant que je sache, les deux signal() et sigaction() sont OK dans les applications multi-thread.)
San
Points
434
Pour moi, c'est en dessous de la ligne a été suffisant pour décider:
Le sigaction() fonction fournit une plus complètes et plus fiables mécanisme de contrôle de signaux; nouveau les applications doivent utiliser sigaction() plutôt que de signal()
http://pubs.opengroup.org/onlinepubs/009695399/functions/signal.html#tag_03_690_07
Si vous êtes à partir de zéro ou de la modification d'un ancien programme, sigaction devrait être la bonne option.
ididak
Points
4208
Ce sont des interfaces différentes pour les installations de signalisation du système d'exploitation. Si possible, préférez utiliser sigaction pour signaler que signal () a un comportement défini par l'implémentation (souvent sujet à la race) et se comporte différemment sous Windows, OS X, Linux et d'autres systèmes UNIX.
Voir cette note de sécurité pour plus de détails.
dmckee
Points
50318
À partir de la page de manuel signal(3) :
LA DESCRIPTION
This signal() facility is a simplified interface to the more general sigaction(2) facility.
Les deux invoquent la même installation sous-jacente. Vous ne devriez probablement pas manipuler la réponse d'un seul signal avec les deux, mais les mélanger ne devrait causer aucune cassure ...
bmdhacks
Points
9074
Je ne l'utiliserais signal() car elle est plus portable, du moins en théorie. Je vais voter tout intervenant qui peut arriver à un système moderne qui n'a pas une couche de compatibilité POSIX et prend en charge le signal().
Citant la GLIBC documentation:
Il est possible d'utiliser à la fois le signal et sigaction fonctions au sein de un seul programme, mais vous devez être prudent, car ils peuvent interagir dans un peu étrange des façons.
La fonction sigaction spécifie plus d'informations que le signal la fonction, de sorte que la valeur de retour de signal ne peut pas exprimer la pleine gamme de sigaction possibilités. Par conséquent, si vous utilisez le signal de enregistrer et, plus tard, rétablir une action, il peut ne pas être en mesure de rétablir correctement un gestionnaire qui a été établi avec sigaction.
Pour éviter d'avoir des problèmes comme un résultat, utilisez toujours sigaction pour enregistrer et de restaurer un gestionnaire si votre programme utilise sigaction. Depuis sigaction est plus général, il peut sauver correctement et de rétablir tous les action, indépendamment du fait qu'il a été créé à l'origine avec signal ou sigaction.
Sur certains systèmes, si vous mettre en place une action avec un signal de puis examiner avec sigaction, le gestionnaire de l'adresse que vous obtenez peut pas être le même que celui que vous avez spécifié avec le signal. Il peut même ne pas être approprié pour l'usage comme un argument d'action avec le signal. Mais vous pouvez compter l'utiliser comme un argument de sigaction. Ce problème n'arrive jamais sur le système GNU.
Donc, il est préférable d'utiliser l'une ou l'autre des mécanismes de de manière cohérente au sein d'un seul programme.
La portabilité Remarque: Le signal de base de la fonction est une fonction de la norme ISO C, alors que sigaction fait partie de la norme POSIX.1 standard. Si vous êtes préoccupé par la portabilité de non-POSIX systèmes, alors vous devriez utilisez la fonction de signal à la place.
Copyright (C) 1996-2008 Free Software Foundation, Inc.
Permission est accordée de copier, distribuer et/ou modifier ce document selon les termes de la Licence de Documentation Libre GNU, Version 1.2 ou toute version ultérieure publiée par la Free Software Foundation; sans Sections inaltérables, sans Avant-Textes de Couverture, et des Textes. Une copie de la licence est inclus dans la section intitulée "Licence de Documentation Libre GNU".
