Réponse.

Historique de la question :

Perl a été créé comme un langage pour les scripts système, donc la gestion des signaux (SIGTERM, SIGINT, SIGHUP) a toujours été une fonctionnalité intégrée et puissante. Ce système permet d'intercepter des événements externes (arrêt de l'utilisateur, redémarrage du démon, délais d'attente) et d'achever ou de modifier correctement le comportement des scripts.

Problème :

Une mauvaise gestion des signaux est une cause fréquente de terminaisons incorrectes ou de blocages de scripts, de perte de données en cas de terminaison anormale et d'impossibilité de redémarrer des processus sans perte d'état ou de ressources.

Solution :

Les signaux sont gérés via l'installation de gestionnaires dans un hachage spécial %SIG. Une bonne pratique consiste à minimiser les actions à l'intérieur du gestionnaire de signal (par exemple, définir un flag et terminer de manière sécurisée dans le fil principal). Pour un fonctionnement correct dans les threads et lors de multiples traitements de signaux, des modules spécialisés sont utilisés (par exemple, POSIX::sigaction).

Exemple :

my $term = 0;
$SIG{TERM} = sub {
    $term = 1;
};
while (1) {
    last if $term;
    # travail principal
}
print "Arrêt gracieux
";

Caractéristiques clés :

Installation d'un gestionnaire de signal via $SIG{SIGNAME} = sub { ... };
Les actions dans le gestionnaire doivent être minimales ; mieux vaut juste définir un flag
Pour des scénarios complexes — utilisation des modules POSIX::sigaction ou SafeSignals

Questions piégeuses.

Peut-on utiliser print/IO à l'intérieur d'un gestionnaire de signal ?

Réponse : Pas recommandé — cela entraînera un fonctionnement incorrect et une possible perte de données ! La norme moderne est d'utiliser un code minimal (uniquement pour définir des flags/nettoyer des variables).

Que se passe-t-il si l'on ne réinitialise pas le gestionnaire de signal après le premier déclenchement ?

Réponse : Le gestionnaire fonctionnera plusieurs fois si le signal arrive à nouveau. Si une réaction ne doit se produire que sur le premier événement, le gestionnaire doit réinitialiser lui-même $SIG{...} ou envoyer des signaux à lui-même.

La gestion des signaux est-elle sécurisée pour les threads dans Perl ?

Réponse : Non ! Dans Perl multithreadé, les gestionnaires de signaux sont appelés uniquement dans le thread principal (interpréteur principal) ; dans les threads, les signaux peuvent être complètement ignorés ou mal traités.

Erreurs typiques et anti-patterns

Effectuer des actions lourdes ou dangereuses dans un gestionnaire de signal
Ignorer des flags — terminaison incorrecte de la boucle ou omission d'erreurs
Insuffisance des tests de fonctionnement dans des applications Perl multithreadées

Exemple de la vie réelle

Cas négatif

Le processus démon, à la réception de SIGTERM, appelle immédiatement close sur tous les descripteurs de fichiers et supprime les fichiers temporaires dans le gestionnaire — de temps en temps, les fichiers ne sont pas supprimés, des données sont perdues.

Avantages :

Réaction instantanée au signal

Inconvénients :

Risque de corruption ou de perte de fichiers si le gestionnaire exécute une longue section de code

Cas positif

Le gestionnaire de signal SIGTERM fixe uniquement la variable $exit, après quoi la boucle principale termine soigneusement son exécution, ferme les fichiers et ne libère les ressources qu'ensuite.