Cosa succede a un processo Linux multithread se riceve un segnale?

Se un processo Unix (Posix) riceve un segnale, verrà eseguito un gestore di segnale.

Cosa gli succederà in un processo multithread? Quale thread riceve il segnale?

A mio avviso, l'API del segnale dovrebbe essere estesa per gestirlo (vale a dire che il thread del gestore del segnale dovrebbe essere in grado di essere determinato), ma cercando informazioni in rete ho trovato solo fiamme di un anno sulla mailing list del kernel di Linux e su forum diversi. Come ho capito, il concetto di Linus differiva dallo standard Posix, e prima fu costruito un livello di compatibilità, ma ora Linux segue il modello posix.

Qual è lo stato attuale?

— peterh - Ripristina Monica
fonte

Duplicato di stackoverflow.com/questions/11679568/... "pthreads (7) descrive che POSIX.1 richiede tutte le discussioni in un attributi azionari processo, comprese le disposizioni di segnale"

— Steve

@steve Grazie, ma 1) è su un altro sito SE 2) questa specifica non specifica chiaramente cosa accadrà esattamente. Che cosa significa, i gestori di segnale verranno chiamati su tutti i thread, ma a me sembra un po 'surreale. 3) Quella risposta non specifica quale fosse il modello di Linus e perché / come sia attualmente utilizzato.

— Peter - Ripristina Monica il

La voce in POSIX su " Generazione e consegna del segnale " in "Motivazione: Informazioni generali sulle interfacce di sistema"

I segnali generati per un processo vengono consegnati a un solo thread. Pertanto, se più di un thread è idoneo a ricevere un segnale, è necessario sceglierne uno. La scelta dei thread viene lasciata interamente all'implementazione sia per consentire la più ampia gamma possibile di implementazioni conformi sia per dare alle implementazioni la libertà di inviare il segnale al thread "più semplice possibile" in caso di differenze nella facilità di consegna tra thread diversi.

Dal signal(7)manuale su un sistema Linux:

Un segnale può essere generato (e quindi in sospeso) per un processo nel suo insieme (ad esempio, quando inviato utilizzando kill(2)) o per un thread specifico (ad esempio, alcuni segnali, come SIGSEGV e SIGFPE, generato come conseguenza dell'esecuzione di una macchina specifica- le istruzioni di lingua sono indirizzate al thread, così come i segnali indirizzati a un thread specifico utilizzando pthread_kill(3)). Un segnale diretto al processo può essere inviato a uno qualsiasi dei thread che al momento non ha il segnale bloccato. Se in uno dei thread è sbloccato il segnale, il kernel sceglie un thread arbitrario a cui inviare il segnale.

E in pthreads(7):

I thread hanno distinte impostazioni di stack del segnale alternativo. Tuttavia, le impostazioni dello stack di segnale alternativo di un nuovo thread vengono copiate dal thread che lo ha creato, in modo che i thread condividano inizialmente uno stack di segnale alternativo (corretto nel kernel 2.6.16).

Dal pthreads(3)manuale su un sistema OpenBSD (come esempio di approccio alternativo):

I gestori di segnali vengono normalmente eseguiti nello stack del thread attualmente in esecuzione.

(Al momento non sono a conoscenza di come questo viene gestito quando più thread vengono eseguiti contemporaneamente su una macchina multi-processore)

La precedente implementazione LinuxThread dei thread POSIX consentiva solo ai singoli thread distinti di essere indirizzati dai segnali. Da pthreads(7)un sistema Linux:

LinuxThreads non supporta la nozione di segnali orientati al processo: i segnali possono essere inviati solo a thread specifici.

— Kusalananda
fonte