Linux (dans la version que tu utilises, avec les paramètres de compilation que tu as passé au noyau, etc.) ait une queue en interne (je ne sais pas comment il gère les signaux).
Dans le cas simple où tu as juste deux programmes en charge CPU, ça passe crème : le noyau va recevoir le signal de l’émetteur, basculer sur le code du récepteur (par optimisation par exemple : le noyau sait que le récepteur a du code à exécuter donc il va préférer basculer sur lui), il va exécuter entièrement le handler, avant de rebasculer sur l’émetteur, et ainsi de suite. Ça peut très bien se passer. Dans un cas de test simple. Mais sur une machine qui a un peu de load ou autre, multi-processeur, etc., rien ne te garantit que le noyau va exécuter alternativement les codes de l’un et de l’autre.
Si tu veux coder propre, il faut pas juste se contenter du "chez moi ça marche" mais prendre en compte les cas de comportement indéterminés. Cela implique de lire la doc à fond. En pur C/posix c’est incontournable. Dans le cas contraire tu t’exposes au risque que ça te pète à la gueule (au pire moment dira Murphy). Ça peut marcher pendant 10 ans, puis un beau jour casser parce que la mécanique interne du noyau et/ou de la lib a changé.
Sinon si t’as un peu de temps et de la motivation, tu peux essayer un émetteur qui envoie 10, 100 voir 1000 signaux dans la boucle la plus rapide possible, un récepteur qui a un handler artificiellement long (absolument via un sleep ou usleep ça obligera le noyau à reprendre la main). Vois si ton handler récupère tous les signaux.
[^] # Re: Ça marche pas.
Posté par ml . En réponse au journal SIGUSR1, SIGUSR2,..., SIGUSR_N ?. Évalué à 4. Dernière modification le 10 mai 2023 à 18:50.
Il est possible que :
Linux (dans la version que tu utilises, avec les paramètres de compilation que tu as passé au noyau, etc.) ait une queue en interne (je ne sais pas comment il gère les signaux).
Dans le cas simple où tu as juste deux programmes en charge CPU, ça passe crème : le noyau va recevoir le signal de l’émetteur, basculer sur le code du récepteur (par optimisation par exemple : le noyau sait que le récepteur a du code à exécuter donc il va préférer basculer sur lui), il va exécuter entièrement le handler, avant de rebasculer sur l’émetteur, et ainsi de suite. Ça peut très bien se passer. Dans un cas de test simple. Mais sur une machine qui a un peu de load ou autre, multi-processeur, etc., rien ne te garantit que le noyau va exécuter alternativement les codes de l’un et de l’autre.
Si tu veux coder propre, il faut pas juste se contenter du "chez moi ça marche" mais prendre en compte les cas de comportement indéterminés. Cela implique de lire la doc à fond. En pur C/posix c’est incontournable. Dans le cas contraire tu t’exposes au risque que ça te pète à la gueule (au pire moment dira Murphy). Ça peut marcher pendant 10 ans, puis un beau jour casser parce que la mécanique interne du noyau et/ou de la lib a changé.
Sinon si t’as un peu de temps et de la motivation, tu peux essayer un émetteur qui envoie 10, 100 voir 1000 signaux dans la boucle la plus rapide possible, un récepteur qui a un handler artificiellement long (absolument via un
sleepouusleepça obligera le noyau à reprendre la main). Vois si ton handler récupère tous les signaux.