Quand un processus reçoit un signal, le noyau va chercher à appeler le gestionnaire de signal associé à celui-ci. S'il n'existe pas, car le processus n'en a pas installé un, il va réaliser le comportement par défaut associé à ce signal. Or à quelques exceptions près, c'est terminer le logiciel voire avec un coredump.
Par contre, si un tel gestionnaire existe, le noyau va appeler ce gestionnaire. Et c'est tout. Ce sera au gestionnaire d'avoir un comportement correct vis à vis du signal reçu. Cela signifie que si tu n'arrêtes pas le programme via un exit() dans le gestionnaire, ce dernier continuera de vivre sa vie.
Cependant, certains signaux comme SIGSEGV ont un comportement indéfini si le programme n'est pas stoppé dans le gestionnaire de signal. C'est donc une mauvaise idée d'essayer de faire poursuivre le programme dans cette situation. En effet, le but d'un gestionnaire de signal est surtout d'essayer de sauver les meubles avant la fin du programme : enregistrer des données sur le disque, ajouter des logs plus précis, etc. Rarement pour essayer de poursuivre l'exécution de celui-ci au delà (car cela ne fait pas forcément sens, et parce que c'est souvent compliqué à réaliser).
Le SIGSEGV est émie par le noyau ou par le MMU ?
La MMU (comme tout composant matériel en fait) n'a aucune notion de ce qu'est POSIX, d'un signal UNIX ou quoique ce soit relatif à tout cela. C'est forcément le noyau qui envoie ce genre de signaux, car c'est son rôle de faire interface entre un logiciel et le matériel.
En fait la MMU va générer une interruption suite à l'erreur mémoire du programmer. Le noyau va recevoir cette interruption (via le gestionnaire d'interruptions) et enverra ensuite le signal au processus fautif.
# Reprenons les bases
Posté par Renault (site web personnel) . En réponse au message combien de temps se passe entre l'émission d'un SIGSEV et SIGKILL. Évalué à 9.
Quand un processus reçoit un signal, le noyau va chercher à appeler le gestionnaire de signal associé à celui-ci. S'il n'existe pas, car le processus n'en a pas installé un, il va réaliser le comportement par défaut associé à ce signal. Or à quelques exceptions près, c'est terminer le logiciel voire avec un coredump.
Par contre, si un tel gestionnaire existe, le noyau va appeler ce gestionnaire. Et c'est tout. Ce sera au gestionnaire d'avoir un comportement correct vis à vis du signal reçu. Cela signifie que si tu n'arrêtes pas le programme via un exit() dans le gestionnaire, ce dernier continuera de vivre sa vie.
Cependant, certains signaux comme SIGSEGV ont un comportement indéfini si le programme n'est pas stoppé dans le gestionnaire de signal. C'est donc une mauvaise idée d'essayer de faire poursuivre le programme dans cette situation. En effet, le but d'un gestionnaire de signal est surtout d'essayer de sauver les meubles avant la fin du programme : enregistrer des données sur le disque, ajouter des logs plus précis, etc. Rarement pour essayer de poursuivre l'exécution de celui-ci au delà (car cela ne fait pas forcément sens, et parce que c'est souvent compliqué à réaliser).
La MMU (comme tout composant matériel en fait) n'a aucune notion de ce qu'est POSIX, d'un signal UNIX ou quoique ce soit relatif à tout cela. C'est forcément le noyau qui envoie ce genre de signaux, car c'est son rôle de faire interface entre un logiciel et le matériel.
En fait la MMU va générer une interruption suite à l'erreur mémoire du programmer. Le noyau va recevoir cette interruption (via le gestionnaire d'interruptions) et enverra ensuite le signal au processus fautif.