quand le signal sera traité dans unix?

Un signal est le mécanisme Unix permettant à un processus d’espace utilisateur de recevoir des notifications asynchrones. En tant que tels, les signaux sont toujours “délivrés par” le kernel. Et par conséquent, il est impossible de transmettre un signal sans passer en mode kernel. Par conséquent, cela n’a pas de sens de parler d’un processus “recevant” un signal (ou en envoyant un) sans l’implication du kernel.

Les signaux peuvent être générés de différentes manières.

• Ils peuvent être générés par un pilote de périphérique dans le kernel (par exemple, le pilote tty en réponse aux touches interruption, kill ou stop ou en réponse à une entrée ou une sortie par un processus en arrière-plan).
• Ils peuvent être générés par le kernel en réponse à une condition de mémoire insuffisante.
• Ils peuvent être générés par une exception de processeur en réponse à quelque chose que le processus lui-même effectue lors de son exécution (instruction illégale, division par zéro, référence à une adresse illégale).
• Ils peuvent être générés directement par un autre processus (ou par le processus de réception lui-même) via kill(2) .
• SIGPIPE peut être généré à la suite de l’écriture sur un canal sans lecteur.

Mais dans tous les cas, le signal est transmis au processus de réception par le kernel et donc par une transition en mode kernel.

Le kernel peut avoir besoin de forcer cette transition – préempter le processus de réception – pour délivrer le signal (par exemple, dans le cas où un processus lié au processeur est exécuté sur un processeur A envoyé un signal par un processus différent en cours d’exécution) sur le processeur B).

Dans certains cas, le kernel peut gérer le signal lui-même (par exemple, avec SIGKILL – ou plusieurs autres si aucun gestionnaire de signal n’est configuré).

Le fait d’appeler un gestionnaire de signal de processus se fait en manipulant la stack d’espace utilisateur du processus afin que le gestionnaire de signaux soit appelé en retour du mode kernel et que, si la procédure du gestionnaire de signaux revienne, le code d’origine puisse être repris.

Quant au traitement, il est soumis à plusieurs facteurs.

• Certaines opérations du système d’exploitation (c’est-à-dire du kernel) ne sont jamais interrompues par des signaux (il s’agit généralement d’opérations de durée relativement courte), auquel cas le signal sera traité après leur achèvement.
• Le processus peut avoir temporairement bloqué la dissortingbution du signal, auquel cas le signal sera “en attente” jusqu’à ce qu’il soit débloqué.
• Le processus peut être échangé ou non exécutable pour un certain nombre de raisons – auquel cas, son gestionnaire de signal ne peut pas être invoqué tant que le processus n’est plus exécutable.
• La reprise du processus afin de délivrer le signal peut être retardée par des interruptions et des tâches de priorité plus élevée.

Un signal sera immédiatement détecté par le processus qui le reçoit. Selon le type de signal, le processus peut le traiter avec le gestionnaire par défaut, peut l’ignorer ou peut exécuter un gestionnaire personnalisé. Cela dépend beaucoup du processus et du signal qu’il reçoit. L’exception est le signal de suppression (9) qui est traité par le kernel et termine l’exécution du processus qui était censé le recevoir.