std::signal

Défini dans l'en-tête `<csignal>`
/signal-handler/* signal( int sig, /signal-handler/* handler );	(1)
extern "C" using /signal-handler/ = void(int);	(2)	(exposition uniquement*)

Modifie la gestion du signal sig. Selon la valeur de handler, le signal peut être ignoré, réglé par défaut, ou traité par une fonction définie par l'utilisateur invoquée comme (*handler)(sig).

Lorsque le gestionnaire de signal est défini sur une fonction et qu'un signal se produit, il est défini par l'implémentation si std::signal(sig, SIG_DFL) sera exécutée immédiatement avant le début du gestionnaire de signal. De plus, l'implémentation peut empêcher un ensemble défini par l'implémentation de signaux de se produire pendant l'exécution du gestionnaire de signal.

Pour certains signaux, l'implémentation peut appeler std::signal(sig, SIG_IGN) au démarrage du programme. Pour les autres, l'implémentation doit appeler std::signal(sig, SIG_DFL).

(Remarque : POSIX a introduit sigaction pour normaliser ces comportements définis par l'implémentation.)

Paramètres

sig

-

le signal pour lequel définir le gestionnaire de signal. Il peut s'agir d'une valeur définie par l'implémentation ou de l'une des valeurs suivantes :

SIGABRTSIGFPESIGILLSIGINTSIGSEGVSIGTERM

définit les types de signaux
(constante de macro)

gestionnaire

-

le gestionnaire de signal. Il doit s'agir de l'un des éléments suivants :

SIG_DFL macro. Le gestionnaire de signal est défini sur le gestionnaire de signal par défaut.
SIG_IGN macro. Le signal est ignoré.
Un pointeur vers une fonction. La signature de la fonction doit être équivalente à la suivante :

extern "C" void fun(int sig);

Valeur de retour

Gestionnaire de signal précédent en cas de succès ou SIG_ERR en cas d'échec (la configuration d'un gestionnaire de signal peut être désactivée sur certaines implémentations).

Gestionnaire de signal

Les limitations suivantes sont imposées à la fonction définie par l'utilisateur qui est installée comme gestionnaire de signal.

Si le gestionnaire de signal est appelé NON comme résultat de std::abort ou std::raise (signal asynchrone), le comportement est indéfini si

le gestionnaire de signal appelle toute fonction de la bibliothèque standard, sauf

std::abort
std::_Exit
std::quick_exit
std::signal avec le premier argument étant le numéro du signal actuellement traité (le gestionnaire asynchrone peut se réenregistrer lui-même, mais pas d'autres signaux).

le gestionnaire de signal fait référence à tout objet avec une durée de stockage statique qui n'est pas std::atomic ou (depuis C++11) volatile std:: sig_atomic_t .

(jusqu'à C++17)

Une opération atomique simple sans verrouillage est un appel d'une fonction f de <atomic> ou <stdatomic.h> (depuis C++23) , telle que :

f est la fonction std::atomic_is_lock_free ,
f est la fonction membre is_lock_free (par exemple std::atomic::is_lock_free() ),
f est une fonction membre non statique de std::atomic_flag ,
f est une fonction non membre, et le premier paramètre de f a le type cv std:: atomic_flag * ,
f est une fonction membre non statique invoquée sur un objet obj , telle que obj. is_lock_free ( ) donne true , ou
f est une fonction non membre, et pour chaque argument pointeur-vers-atomique arg passé à f , std:: atomic_is_lock_free ( arg ) donne true .

Le comportement est indéfini si un gestionnaire de signal effectue l'une des actions suivantes :

appel à toute fonction de bibliothèque, sauf pour les opérations atomiques simples sans verrouillage et les fonctions sûres pour les signaux suivantes (noter, en particulier, que l'allocation dynamique n'est pas sûre pour les signaux) :

std::signal avec le premier argument étant le numéro du signal actuellement traité (le gestionnaire de signal peut se réenregistrer lui-même, mais pas d'autres signaux).
fonctions membres de std::numeric_limits
std::_Exit
std::abort
std::quick_exit
Les fonctions membres de std::initializer_list et les surcharges std::initializer_list de std::begin et std::end
std::forward , std::move , std::move_if_noexcept
Toutes les fonctions de <type_traits>
std::memcpy et std::memmove

accès à un objet avec une durée de stockage de thread
une expression dynamic_cast
une expression throw
entrée dans un try block
initialisation d'une variable statique qui effectue une initialisation dynamique non locale (y compris retardée jusqu'à la première utilisation ODR)
attend la fin de l'initialisation de toute variable avec une durée de stockage statique due à son initialisation concurrente par un autre thread

(depuis C++17)

Si la fonction définie par l'utilisateur retourne lors du traitement de SIGFPE , SIGILL , SIGSEGV ou tout autre signal défini par l'implémentation spécifiant une exception de calcul, le comportement est indéfini.

Si le gestionnaire de signal est appelé suite à std::abort ou std::raise (signal synchrone), le comportement est indéfini si le gestionnaire de signal appelle std::raise .

À l'entrée du gestionnaire de signal, l'état de l'environnement à virgule flottante et les valeurs de tous les objets sont non spécifiés, sauf pour

les objets de type volatile std:: sig_atomic_t

les objets de types std::atomic sans verrouillage
les effets secondaires rendus visibles via std::atomic_signal_fence

(depuis C++11)

Au retour d'un gestionnaire de signal, la valeur de tout objet modifié par le gestionnaire de signal qui n'est pas volatile std:: sig_atomic_t ou std::atomic sans verrouillage est indéterminée.

(jusqu'à C++14)

Un appel à la fonction signal() se synchronise-avec toute invocation résultante du gestionnaire de signal.

Si un gestionnaire de signal est exécuté à la suite d'un appel à std::raise (de manière synchrone), alors l'exécution du gestionnaire est séquencée-après l'invocation de std::raise et séquencée-avant le retour de celle-ci, et s'exécute sur le même thread que std::raise . L'exécution des gestionnaires pour d'autres signaux est non séquencée par rapport au reste du programme et s'exécute sur un thread non spécifié.

Deux accès au même objet de type volatile std:: sig_atomic_t n'entraînent pas de course de données s'ils se produisent dans le même thread, même si un ou plusieurs se produisent dans un gestionnaire de signal. Pour chaque invocation de gestionnaire de signal, les évaluations effectuées par le thread invoquant un gestionnaire de signal peuvent être divisées en deux groupes A et B, de sorte qu'aucune évaluation dans B ne se produit-avant les évaluations dans A, et les évaluations de ces volatile std:: sig_atomic_t prennent des valeurs comme si toutes les évaluations dans A se produisaient-avant l'exécution du gestionnaire de signal et l'exécution du gestionnaire de signal se produisait-avant toutes les évaluations dans B.

(depuis C++14)

Notes

POSIX exige que signal soit thread-safe, et spécifie une liste de fonctions de bibliothèque sûres pour les signaux asynchrones pouvant être appelées depuis n’importe quel gestionnaire de signaux.

Les gestionnaires de signaux sont censés avoir une liaison C et, en général, utiliser uniquement les fonctionnalités du sous-ensemble commun du C et du C++. Cependant, les implémentations courantes permettent qu’une fonction avec une liaison C++ soit utilisée comme gestionnaire de signaux.

Exemple

Exécuter ce code

#include <csignal>
#include <iostream>
namespace
{
    volatile std::sig_atomic_t gSignalStatus;
}
void signal_handler(int signal)
{
    gSignalStatus = signal;
}
int main()
{
    // Installer un gestionnaire de signal
    std::signal(SIGINT, signal_handler);
    std::cout << "SignalValue: " << gSignalStatus << '\n';
    std::cout << "Sending signal: " << SIGINT << '\n';
    std::raise(SIGINT);
    std::cout << "SignalValue: " << gSignalStatus << '\n';
}

Sortie possible :

SignalValue: 0
Sending signal: 2
SignalValue: 2

Références

Norme C++23 (ISO/CEI 14882:2024) :

17.13.5 Gestionnaires de signaux [support.signal]

Norme C++20 (ISO/CEI 14882:2020) :

17.13.5 Gestionnaires de signaux [support.signal]

Norme C++17 (ISO/IEC 14882:2017) :

21.10.4 Gestionnaires de signaux [support.signal]

Rapports de défauts

Les rapports de défauts modifiant le comportement suivants ont été appliqués rétroactivement aux normes C++ précédemment publiées.

DR	Applicable à	Comportement publié	Comportement corrigé
LWG 3756	C++17	il n'était pas clair si std::atomic_flag est sûr pour les signaux	il l'est

Voir aussi

raise	exécute le gestionnaire de signal pour un signal particulier (fonction)
atomic_signal_fence (C++11)	barrière entre un thread et un gestionnaire de signal exécuté dans le même thread (fonction)
Documentation C pour signal

Support du compilateur
Autonome et hébergé
Langage
Bibliothèque standard
En-têtes de la bibliothèque standard
Exigences nommées
Macros de test de fonctionnalités (C++20)
Bibliothèque de support linguistique
Bibliothèque de concepts (C++20)
Bibliothèque de diagnostics
Bibliothèque de gestion de la mémoire
Bibliothèque de métaprogrammation (C++11)
Bibliothèque d'utilitaires généraux
Bibliothèque de conteneurs
Bibliothèque d'itérateurs
Bibliothèque de plages (C++20)
Bibliothèque d'algorithmes
Bibliothèque de chaînes
Bibliothèque de traitement de texte
Bibliothèque numérique
Bibliothèque de date et heure
Bibliothèque d'entrée/sortie
Bibliothèque de systèmes de fichiers (C++17)
Bibliothèque de support de la concurrence (C++11)
Bibliothèque de contrôle d'exécution (C++26)
Spécifications techniques
Index des symboles
Bibliothèques externes

fr.cppreference.net

Namespaces

Variants