Comment un processus à savoir qu'il a reçu un signal
s'il vous Plaît corrigez-moi si je me trompe. Voici ma compréhension des signaux:
autant que je sache, génération de signal et la livraison de signal sont 2 différents chose. Afin de générer un signal, L'OS place simplement un peu dans un bitarray maintenu dans le contrôle du processus Bloc (PCB) du procédé. Chaque bit correspond à un signal, et quand un peu est mis, cela signifie le signal correspondant au bit est attente.
Livraison: Avant de transférer le contrôle retour à un processus en mode utilisateur, l' Le noyau vérifie toujours l'attente des signaux pour ce processus. Cette case doit se produire dans l'espace du Noyau, car certains signaux ne peuvent jamais être ignoré par un processus-à savoir SIGSTOP et SIGKILL.
cela signifie donc que les signaux ne peuvent être livrés à un processus que lorsque le noyau planifie ce processus I. l'allocation de L'UNITÉ CENTRALE? Est-ce qu'un processus peut recevoir un signal lorsqu'il est réellement exécuté sur le CPU ? Si oui, comment est-il possible que I. e comment le processus en vient à savoir qu'un signal est en attente pour lui (puisqu'il est exécuté en mode utilisateur et ne peut pas accéder au PCB)
supposons qu'il y ait une machine multi-processeurs et donc qu'il y ait un vrai parallélisme I. e plusieurs processus sont exécutés en même temps. Le processus P1 est exécuté sur cpu 1 et le processus P2 est exécuté sur cpu2 et maintenant le processus P2(ayant suffisamment de privilèges) envoie un signal au processus P1. Sera ce signal sera livrée à P1 maintenant, ou qu'il sera livré après que P1 abandonne le CPU pour une raison quelconque et est de nouveau reprogrammé plus tard par le noyau et ce signal est ensuite livré au processus P1.
Merci de ne pas dire que cette question est dépendant de l'implémentation. Si vous trouvez que la bonne réponse est implémentation définie, alors je suis à la recherche de réponses sous Linux, FreeBSD ou n'importe quelle plate-forme *nix que vous connaissez.
Merci beaucoup pour votre aide et votre patience :)
Cordialement
île
4 réponses
La réponse est dépendant de l'implémentation :). Sur Mac OS X (et FreeBSD), les signaux sont traités de manière asynchrone - le noyau trouve un thread qui ne bloque pas le signal, et met un drapeau de trappe système asynchrone sur ce thread. La prochaine fois que le noyau planifie le thread, il gère le trap (arrêter le processus, ignorer le trap, ou invoquer le gestionnaire de signal dans l'espace utilisateur) plutôt que d'organiser la suite habituelle du thread dans l'espace utilisateur.
sur Solaris, la mise en œuvre est quelque peu similaire, bien qu'elle offre également des signaux synchrones basés sur des pièges matériels - les signaux synchrones sont livrés au thread qui a soulevé le piège, tandis que les signaux asynchrones fonctionnent de la manière décrite ci-dessus.
Linux fait quelque chose de similaire à Solaris (Je ne suis pas sûr que la conclusion de cette référence découle de la discussion, mais c'est la discussion qui est utile).
Posix.4 définit également le temps réel les signaux, mais je n'ai pas travaillé avec ceux-ci.
la réponse courte est-oui, le processus obtenir la connaissance d'un signal seulement sur le prochain calendrier CPU prévu.
Comment savoir que le processus a reçu un signal - il peut appeler sigprocmask(2).
le processus P1 s'exécute sur cpu 1 et le processus P2 s'exécute sur cpu2 et maintenant le processus P2(ayant suffisamment de privilèges) envoie un signal au processus P1. Ce signal sera-t-il livré à P1 dès maintenant ou sera-t-il livré après que P1 aura abandonné le CPU pour une raison quelconque et sera de nouveau reprogrammé plus tard par le noyau et alors ce signal sera livré au processus P1.
autant que je sache sur les derniers noyaux linux, l'exécution de P1 peut être interrompue lorsque P2 émet signal et signal seront livrés immédiatement. Peut-être ce vrai que pour les signaux temps réel
si je me souviens bien, le bit d'arrivée de l'interruption est vérifié pendant le dernier état T d'une instruction 8085. Il doit donc y avoir un moyen de générer une réelle interruption à l'arrivée du signal, ou il doit y avoir une constante?) tranche de code avant vérification du bit de signal.
malheureusement, il semble que la seule façon de répondre à certaines questions relatives au comportement du noyau est de passer en revue le code source, parce qu'il est tellement "dépendant de l'implémentation". Programmation de l'ordinateur en réalité, ce n'est rien de moins que du harcèlement - quelle profession choisir!
Juste essayer d'être parfait, et espérons que ce site aide.