Un signal envoyé avec kill à un thread parent est-il garanti d’être traité avant la prochaine instruction?

Bon, donc si je suis sous un thread enfant sur Linux (en utilisant pthreads si ça compte), et que je lance la commande suivante

kill(getpid(), someSignal); 

il enverra le signal donné au parent du thread actuel.

Ma question: est-il garanti que le parent obtiendra immédiatement le processeur et traitera le signal (tuer l’application s’il s’agit d’un SIGKILL ou faire ce qu’il en est s’il s’agit d’un autre signal) avant l’exécution de l’instruction qui suit kill() ? Ou est-il possible – voire probable – que la commande qui suit soit exécutée par kill() avant que le signal ne soit traité par le thread parent?

Les signaux sont livrés de manière asynchrone, vous ne pouvez donc pas vous attendre à ce que le fil les manipulant les traite immédiatement; de plus, il devra faire quelques efforts pour le gérer.

Et si un appel sigprocmask () avait masqué le signal dans tous les threads, le signal ne sera traité qu’après son démasquage.

Les signaux ne vont à aucun fil particulier, sauf si vous avez utilisé sigprocmask pour les masquer des fils que vous ne voulez pas obtenir. La plupart des programmes multithread font cela, car avoir des signaux de niveau processus transmis à des threads arbitraires n’est généralement pas ce que vous voulez.

Non, ce n’est pas garanti.

En règle générale, vous ne pouvez faire aucune hypothèse sur le calendrier d’événements se produisant dans des threads (ou processus) distincts, sauf si vous utilisez un mécanisme de synchronisation explicite (par exemple, un phtread_mutex ou un sémaphore).

Cela est particulièrement vrai sur les systèmes multiprocesseurs (ou multicœurs), où plusieurs threads peuvent s’exécuter littéralement simultanément sur des processeurs distincts, mais même sur un système à un seul processeur, aucune garantie n’est offerte.

Les signaux envoyés à un processus (groupe de threads) peuvent généralement être livrés à n’importe quel thread et vous n’avez généralement aucune garantie que le gestionnaire aura fini avant le retour de l’interruption.

Si tu cours

 kill(getpid(), someSignal); 

dans un processus multithread, vous pouvez uniquement être sûr que votre gestionnaire sig sera exécuté avant que kill retourne dans un scénario très spécifique, où tous les threads appelants ont bloqué someSignal (dans ce cas, le gestionnaire sig sera exécuté à partir du thread qui appelle kill ).

Voir http://pubs.opengroup.org/onlinepubs/009695399/functions/kill.html :

Si la valeur de pid provoque la génération de sig pour le processus d’envoi, et si sig n’est pas bloqué pour le thread appelant et si aucun autre thread n’a sig débloqué ou attend dans une fonction sigwait () pour sig, soit sig, soit au moins un signal non bloqué en attente doit être envoyé au thread d’envoi avant le retour de kill ().