Comment puis-unix signaux travail?

L'explication ci-dessous n'est pas exact, et plusieurs aspects de la façon dont cela fonctionne diffèrent entre différents systèmes (et peut-être même le même système d'exploitation sur un matériel différent pour certaines parties), mais je pense qu'il est généralement bonne assez pour vous de satisfaire votre curiosité assez pour les utiliser. La plupart des gens commencent à l'aide des signaux dans la programmation sans même ce niveau de compréhension, mais avant que je sois à l'aise de les utiliser, je voulais comprendre.

signal de livraison

Le noyau de système d'exploitation dispose d'une structure de données appelée de processus de bloc de contrôle pour chaque processus en cours d'exécution qui a les données relatives à ce processus. Ceci peut être regardé par l'id de processus (PID) et inclus un tableau de signal d'actions et dans l'attente de signaux.

Lorsqu'un signal est envoyé à un processus du noyau de système d'exploitation va chercher les processus de processus de bloc de contrôle et examine le signal de l'action de la table de localiser l'action pour le signal envoyé. Si le signal de valeur de l'action est SIG_IGN puis le nouveau signal est oublié par le noyau. Si le signal de valeur de l'action est SIG_DFL alors le noyau de recherche par défaut de traitement de signal d'action pour ce signal dans une autre table et des préformes de cette action. Si les valeurs sont rien d'autre alors que c'est supposé être une fonction de l'adresse dans le processus, le signal est envoyé à ce qui doit être appelé. Les valeurs de SIG_IGN et SIG_DFL sont des nombres exprimés à des pointeurs de fonction dont les valeurs ne sont pas les adresses valides à l'intérieur d'un espace d'adressage du processus (tels que 0 et 1, qui sont à la fois dans la page 0, ce qui n'est jamais mappé dans un processus).

Si un signal fonction de gestion ont été enregistrés par le processus (le signal de valeur de l'action était ni SIG_IGN ou SIG_DFL) puis une entrée dans l'attente du signal de table est fait pour que le signal et que le processus est marqué comme prêt à fonctionner (il peut avoir été en attente sur quelque chose, comme les données disponibles pour un appel à read, en attente d'un signal, ou de plusieurs autres choses).

Maintenant la prochaine fois que le processus est exécuté le noyau de système d'exploitation sera d'abord ajouter des données dans la pile et modifie le pointeur d'instruction pour que le processus, de sorte qu'il semble presque comme si le processus lui-même a juste appelé le gestionnaire de signal. Ce n'est pas tout à fait correcte et la réalité s'écarte assez de ce qui se passe réellement que je vais en parler plus en un peu.

Le gestionnaire de signal fonction peut faire ce qu'il fait (c'est une partie du processus qu'il a été appelé au nom de, de sorte qu'il a été écrit avec des connaissances sur ce que le programme doit faire avec ce signal). Lorsque le gestionnaire de signal renvoie ensuite le code standard pour le processus commence à exécuter de nouveau. (encore une fois, pas précis, mais plus sur que la prochaine)

Ok, le ci-dessus devrait vous donner une assez bonne idée de la façon dont les signaux sont livrés à un processus. Je pense que ce assez bonne idée version est nécessaire avant de pouvoir saisir toute l'idée, qui comprend plus de choses compliquées.

Très souvent le noyau de système d'exploitation a besoin de savoir quand un gestionnaire de signal retourne. C'est parce que les gestionnaires de signaux prendre un argument (ce qui peut nécessiter d'espace de pile), vous pouvez bloquer le même signal de remis deux fois au cours de l'exécution du gestionnaire de signal, et/ou ont des appels système redémarré après qu'un signal est délivré. Pour accomplir ceci, un peu plus de pile et le pointeur d'instruction des changements.

Ce qui doit arriver, c'est que le noyau a besoin pour rendre le processus de dire qu'il a fini de s'exécuter le gestionnaire de signal fonction. Cela peut être fait par une cartographie de la section de la mémoire vive en l'espace d'adressage du processus qui contient le code pour faire cet appel système et de faire de l'adresse de retour pour le gestionnaire de signal fonction (la valeur supérieure de la pile lorsque cette fonction a commencé en cours d'exécution) l'adresse de ce code. Je pense que c'est la façon dont c'est fait dans Linux (au moins les versions plus récentes). Une autre façon d'accomplir ceci (je ne sais pas si cela se fait, mais il pourrait l'être, voulez être ne font de l'adresse de retour pour le gestionnaire de signal fonction d'une adresse non valide (comme NULL) qui pourrait entraîner une interruption sur la plupart des systèmes, ce qui donnerait le noyau de système d'exploitation de nouveau le contrôle. Il n'importe pas beaucoup comment cela se passe, mais le noyau a à obtenir le contrôle de nouveau pour fixer vers le haut de la pile et de savoir que le gestionnaire de signal est terminé.

TOUT EN REGARDANT DANS UNE AUTRE QUESTION, J'AI APPRIS

que le noyau Linux ne carte d'une page dans le processus, mais que l'appel système pour l'enregistrement des gestionnaires de signaux (ce qui sigaction appels ) prend un paramètre sa_restore paramètre, qui est une adresse qui doit être utilisée comme adresse de retour à partir du gestionnaire de signal, et le noyau juste fait en sorte qu'il y est mis. Le code à cette adresse les questions de la je suis fait appel système (sigreturn)et le noyau sait que le gestionnaire de signal est terminé.

de génération de signal de

Je suis la plupart du temps en supposant que vous savez comment les signaux sont générés dans la première place. Le système d'exploitation peut générer, pour le compte d'un processus qui doit se passer quelque chose, comme une minuterie expire, un processus enfant en train de mourir, l'accès à la mémoire qu'il ne faut pas l'accès ou l'émission d'une instruction qu'il ne devrait pas (soit une instruction qui n'existe pas ou qui est privilégié), ou bien d'autres choses. La minuterie cas est fonctionnellement un peu différent des autres, car il peut se produire lorsque le processus n'est pas en cours d'exécution, et est donc plus, comme les signaux envoyés avec le kill appel système. Pour les non-minuterie de signaux envoyés sur le compte de l'actuel processus celles-ci sont générées lorsqu'une interruption se produit parce que le processus actuel est en train de faire quelque chose de mal. Cette interruption donne le noyau de contrôle (comme un système d'appel) et le noyau génère le signal pour être livrés à la processus actuel.

Certaines questions qui ne sont pas abordées dans toutes les déclarations ci-dessus sont multi core, la course dans l'espace du noyau lors de la réception d'un signal, de dormir dans l'espace du noyau lors de la réception d'un signal, l'appel système redémarrage et gestionnaire de signal de temps de latence.

Ici sont un couple de questions à prendre en considération:

• Que si le noyau sait qu'un signal doit être livré au processus X qui est en cours d'exécution sur CPU_X, mais le noyau apprend à ce sujet lors de l'exécution sur CPU_Y (CPU_X!=CPU_Y). Si le noyau a besoin d'arrêter le processus de l'exécution sur une autre base.
• Que si le processus est en cours d'exécution dans l'espace du noyau lors de la réception d'un signal? Chaque fois qu'un processus effectue un appel système, il entre dans l'espace du noyau et bricole avec des structures de données et les allocations de mémoire dans l'espace du noyau. Tout cela piratage de prendre place dans l'espace noyau trop?
• Que si le processus est endormi dans l'espace noyau d'attente pour certains d'autres cas? (lire, écrire, signal, sondage, mutex sont que quelques options).

Réponses:

• Si le processus est en cours d'exécution sur un autre PROCESSEUR le noyau, via la croix-PROCESSEUR de communication, prononcera une interruption de l'autre CPU et un message pour elle. Les autres CPU, du matériel, de la sauver de l'état et de sauter vers le noyau sur les autres CPU, puis fera la livraison du signal sur l'autre CPU. C'est toute une partie de l'essayer, de ne pas exécuter le gestionnaire de signal du processus sur un autre PROCESSEUR qui va casser la localité de cache.
• Si le processus est en cours d'exécution dans l'espace noyau, il n'est pas interrompu. Au lieu de cela, il est constaté que ce processus a reçu un signal. Lorsque le processus s'arrête l'espace noyau (à la fin de chaque appel système), le noyau d'installation le trampoline pour exécuter le gestionnaire de signal.
• Si le processus, lors de l'exécution dans l'espace noyau, après avoir reçu un signal, atteint une fonction de veille, alors que la fonction de veille (ce qui est commun à toutes les fonctions du sommeil dans le noyau) permet de vérifier si le processus a un signal en attente. Si c'est le cas, il ne sera pas mis le processus de sommeil et au lieu d'annuler tout ce qui a été fait en venant vers le bas dans le noyau, et la sortie à l'espace utilisateur lors de la configuration d'un trampoline pour exécuter le gestionnaire de signal, puis redémarrez le système d'appel. Vous pouvez réellement contrôler les signaux que vous voulez interrompre les appels système et que vous n'avez pas l'aide de la siginterrupt(2) appel système. Vous pouvez décider si vous voulez que les appels système redémarrage d'un certain signal lorsque vous vous enregistrez le signal à l'aide sigaction(2) avec le SA_RESTART drapeau. Si un système d'appel est lancé et est coupé par un signal et ne redémarre pas automatiquement, vous obtiendrez un EINTR (interrompu) valeur de retour et vous devez gérer cette valeur. Vous pouvez également regarder la restart_syscall(2) appel système pour plus de détails.
• Si le processus est déjà en veille ou en attente dans l'espace noyau (en fait tout le sommeil/l'attente est toujours dans l'espace du noyau), il est réveillé du sommeil, le code du noyau nettoie après lui-même et d'aller à gestionnaire de signal sur le retour à l'espace utilisateur, après quoi l'appel système est redémarré automatiquement si l'utilisateur le désire (très similaire à la précédente explication de ce qui se passe si le processus est en cours d'exécution dans l'espace noyau).

Quelques notes sur le pourquoi de tout cela est complexe:

• Vous ne pouvez pas simplement s'arrêter un processus qui s'exécute dans l'espace du noyau depuis le développeur du noyau alloue de la mémoire, fait des choses pour les structures de données et plus encore. Si vous venez de prendre le contrôle de vous corrompre l'état du noyau et de provoquer une machine à accrocher. Le code du noyau doit être informé d'une manière contrôlée et qu'il doit arrêter sa course, le retour à l'utilisateur de l'espace et permettre à l'utilisateur de l'espace pour traiter le signal. Cela se fait via la valeur de retour de tous (enfin, presque tous) les fonctions du sommeil dans le noyau. Noyau et les programmeurs sont tenus de traiter ces valeurs de retour avec respect et agir en conséquence.
• Signaux sont asynchrones. Cela signifie qu'ils devraient être livrés dès que possible. Imaginez un processus qui n'a qu'un seul thread, est allé à dormir pendant des heures, et est livré à un signal. Le sommeil est à l'intérieur du noyau. Si vous sauf le code du noyau de se réveiller, de nettoyer après lui-même, de retour à l'espace utilisateur et exécuter le gestionnaire de signal, éventuellement redémarrer le système d'appel après le gestionnaire de signal terminé. Vous n'avez certainement pas s'attendre à ce que le processus à exécuter uniquement le gestionnaire de signal d'une heure plus tard. Ensuite, vous vous attendez à la veille de reprendre. La grande difficulté est prise par l'utilisateur de l'espace et les gens du noyau pour permettre cela.
• Tous dans tous les signaux sont comme des gestionnaires d'interruption, mais pour l'espace utilisateur. C'est une bonne analogie, mais pas parfait. Alors que les gestionnaires d'interruption sont générés par le matériel de certains gestionnaires de signaux proviennent de matériel, mais la plupart sont juste des logiciels (signal sur un processus enfant en train de mourir, le signal d'un autre processus à l'aide de la kill(2) syscall et plus).

Alors, quel est le temps de latence de traitement de signal?

• Si quand vous obtenez un signal à un autre processus est en cours d'exécution, puis le noyau planificateur de décider si, de laisser les autres processus de finition de sa tranche de temps, et seulement ensuite délivrer le signal ou non. Si vous êtes sur un ordinaire système Linux/Unix cela signifie que vous pourriez être retardée par 1 ou plusieurs tranches de temps avant d'obtenir le signal (ce qui signifie en millisecondes, qui sont l'équivalent de l'éternité).
• Lorsque vous obtenez un signal, si votre processus de haute priorité ou d'autres processus ont déjà obtenu leur tranche de temps, vous obtiendrez le signal assez rapide. Si vous exécutez dans l'espace utilisateur, vous l'obtiendrez "immédiatement", si vous exécutez dans l'espace noyau, vous aurez peu de temps à atteindre une fonction de veille ou de retour de noyau auquel cas, lorsque vous revenez à l'utilisateur de l'espace de votre gestionnaire de signal sera appelée. C'est généralement un court laps de temps depuis pas mal de temps est passé dans le noyau.
• Si vous dormez dans le noyau, et rien d'autre n'est au-dessus de votre priorité ou à exécuter, le thread du noyau de la manipulation de votre appel système est réveillé, nettoie après tous les trucs qu'il a fait sur le chemin vers le bas dans le noyau, remonte à l'espace utilisateur et exécute votre signal. Cela ne prendra pas trop de temps (parlions microsecondes ici).
• Si vous êtes en cours d'exécution en temps réel version de Linux et de votre processus de a la la plus élevée en temps réel priorité, puis vous obtiendrez le signal très peu de temps après il est déclenché. Parlions de 50 microsecondes ou encore mieux (dépend d'autres facteurs que je ne peux pas).