Comment les gestionnaires de signaux asynchrones sont-ils exécutés sous Linux?

Question

Je voudrais savoir exactement comment l'exécution asynchrone les gestionnaires de signaux fonctionne sur Linux. Tout d'abord, je ne sais pas à qui thread exécute le gestionnaire de signal. Deuxièmement, je voudrais savoir les étapes à suivre pour rendre le fil d'exécuter le gestionnaire de signal.

Sur la première question, j'ai lu deux, apparemment contradictoires, explications:

1. Le Noyau Linux, par Andries Brouwer, §5.2 "la Réception de signaux" les états:

   Lorsqu'un signal arrive, le processus est interrompu, les registres actuels sont enregistrés, et le gestionnaire de signal est invoquée. Lorsque le gestionnaire de signal retourne, l'interruption de l'activité est poursuivie.

2. Le StackOverflow question "Traiter Avec Asynchrone Signaux Multi Threaded Programme" m'amène à penser que le comportement de Linux est comme SCO Unix est:

   Lorsqu'un signal est transmis à un processus, s'il est pris, il sera traité par un, et un seul, d'entre les fils de la réunion de l'une des conditions suivantes:

   1. Un thread bloqué dans un sigwait(2) de l'appel système dont l'argument ne comprennent le type de choper le signal.

   2. Un thread dont le signal de masque de ne pas inclure le type de choper le signal.

   Autres considérations:

   • Un thread bloqué dans sigwait(2) , la préférence est donnée sur un thread ne bloque pas le type de signal.
   • Si plus d'un thread répond à ces exigences (peut-être deux threads d'appel sigwait(2)), puis l'un d'eux sera choisi. Ce choix n'est pas prévisible par les programmes d'application.
   • Si aucun thread n'est admissible, le signal reste `en attente" au niveau du processus jusqu'à ce fil devient admissible.

   Aussi, "L'Linux Signaux Modèle de gestion" par Moshe Bar états "Asynchrone signaux sont livrés pour le premier thread trouvé pour ne pas bloquer le signal.", qui-je l'interpréter à dire que le signal est remis à un thread ayant son sigmask pas compris le signal.

Laquelle est la bonne?

Sur la deuxième question, ce qui se passe à la pile et le contenu d'un registre pour le fil? Supposons que le fil-à-exécutez-le-signal-gestionnaire de T est dans le milieu de l'exécution d'un do_stuff() fonction. Est thread T's de la pile utilisée directement pour exécuter le gestionnaire de signal (c'est à dire l'adresse du signal trampoline est poussé sur T's de la pile et le contrôle de flux va pour le gestionnaire de signal)? Sinon, est séparé de la pile utilisée? Comment ça fonctionne?

Answer 1

Ces deux explications ne sont pas vraiment contradictoire, si l'on tient compte du fait que Linux les pirates ont tendance à être confus au sujet de la différence entre un fil et un processus, principalement en raison de l'historique de l'erreur d'essayer de faire semblant de threads peuvent être mis en œuvre en tant que processus qui partagent la mémoire. :-)

Cela dit, l'explication #2 est beaucoup plus détaillées, complètes et correctes.

Comme pour la pile et le contenu d'un registre, chaque thread peut enregistrer son propre signal alternatif de manipulation de la pile, et le processus peut choisir, par-signal de base les signaux qui seront livrés sur un autre signal de la manipulation des piles. L'interruption du contexte (registres, masque de signal, etc.) sera enregistré en ucontext_t sur la structure (éventuellement suppléant) de la pile du thread, avec le trampoline à l'adresse de retour. Les gestionnaires de signaux installé avec l' SA_SIGINFO drapeau sont en mesure d'examiner cette ucontext_t structure si ils aiment, mais le seul portable chose qu'ils peuvent faire, c'est d'examiner (et éventuellement modifier) les sauvés masque de signal. (Je ne suis pas sûr si une modification est sanctionné par la norme, mais il est très utile, car il permet au gestionnaire de signal pour atomiquement remplacer l'interruption du code du masque de signal lors de la restitution, par exemple de laisser le signal bloqué de sorte qu'il ne peut pas se produire à nouveau.)