pthreads(7) descrive che POSIX.1 richiede che tutti i thread in un processo condividano gli attributi, inclusi:
- disposizioni di segnale
POSIX.1 richiede inoltre che alcuni attributi siano distinct per ogni thread, incluso:
-
maschera di segnalazione (
pthread_sigmask(3)) -
stack di segnale alternativo (
sigaltstack(2))
Il complete_signal del kernel Linux routine ha il seguente blocco di codice -- i commenti sono abbastanza utili:
/*
* Now find a thread we can wake up to take the signal off the queue.
*
* If the main thread wants the signal, it gets first crack.
* Probably the least surprising to the average bear.
*/
if (wants_signal(sig, p))
t = p;
else if (!group || thread_group_empty(p))
/*
* There is just one thread and it does not need to be woken.
* It will dequeue unblocked signals before it runs again.
*/
return;
else {
/*
* Otherwise try to find a suitable thread.
*/
t = signal->curr_target;
while (!wants_signal(sig, t)) {
t = next_thread(t);
if (t == signal->curr_target)
/*
* No thread needs to be woken.
* Any eligible threads will see
* the signal in the queue soon.
*/
return;
}
signal->curr_target = t;
}
/*
* Found a killable thread. If the signal will be fatal,
* then start taking the whole group down immediately.
*/
if (sig_fatal(p, sig) &&
!(signal->flags & SIGNAL_GROUP_EXIT) &&
!sigismember(&t->real_blocked, sig) &&
(sig == SIGKILL || !p->ptrace)) {
/*
* This signal will be fatal to the whole group.
*/
Quindi, vedi che tu sono responsabili di dove vengono consegnati i segnali:
Se il tuo processo ha impostato la disposizione di un segnale su SIG_IGN o SIG_DFL , quindi il segnale viene ignorato (o predefinito -- kill, core o ignore) per tutti i thread.
Se il tuo processo ha impostato la disposizione di un segnale su una specifica routine del gestore, puoi controllare quale thread riceverà i segnali manipolando specifiche maschere di segnale del thread usando pthread_sigmask(3) . Puoi nominare un thread per gestirli tutti, o creare un thread per segnale, o qualsiasi combinazione di queste opzioni per segnali specifici, oppure fare affidamento sull'attuale comportamento predefinito del kernel Linux di consegnare il segnale al thread principale.
Alcuni segnali, tuttavia, sono speciali secondo il signal(7) pagina man:
Un segnale può essere generato (e quindi in attesa) per un processo nel suo complesso (ad esempio, quando inviato utilizzando kill(2)) o per un thread specifico (ad esempio, alcuni segnali, come SIGSEGV e SIGFPE, generati come conseguenza dell'esecuzione di un specifiche istruzioni in linguaggio macchina sono dirette al thread, così come i segnali mirati a un thread specifico usando pthread_kill(3)). Un segnale diretto dal processo può essere inviato a uno qualsiasi dei thread che al momento non ha il segnale bloccato. Se più di uno dei thread ha il segnale sbloccato, allora il kernel sceglie un thread arbitrario a cui inviare il segnale.
Questo è leggermente sfumato, in base alla versione del kernel Linux che stai usando.
Supponendo 2.6 thread posix e se si parla del sistema operativo che invia SIGTERM o SIGHUP, il segnale viene inviato al processo, che viene ricevuto e gestito dal thread root. Utilizzando i thread POSIX, puoi anche inviare SIGTERM anche a singoli thread, ma sospetto che tu stia chiedendo cosa succede quando il sistema operativo invia il segnale al processo.
Nella versione 2.6, SIGTERM causerà l'uscita "pulita" dei thread figlio, mentre nella versione 2.4, i thread figlio sono stati lasciati in uno stato indeterminato.