O que acontece com um processo Linux multiencadeado se receber um sinal?

Question

Se um processo Unix (Posix) receber um sinal, um manipulador de sinal será executado.

O que acontecerá com isso em um processo multithread? Qual encadeamento recebe o sinal?

Na minha opinião, a API de sinal deve ser estendida para lidar com isso (ou seja, o segmento do manipulador de sinal deve ser determinado), mas procurando por informações na rede. Eu encontrei apenas chamas de ano no mailing do kernel do Linux lista e em diferentes fóruns. Como eu entendi, o conceito de Linus diferiu do padrão Posix, e primeiro foi construída uma camada de compatibilidade, mas agora o Linux segue o modelo posix.

Qual é o estado atual?

    

Answer 1

A entrada em POSIX em " Geração e Entrega de Sinal " em "Fundamentação: Informações Gerais sobre Interfaces de Sistema "diz

Signals generated for a process are delivered to only one thread. Thus, if more than one thread is eligible to receive a signal, one has to be chosen. The choice of threads is left entirely up to the implementation both to allow the widest possible range of conforming implementations and to give implementations the freedom to deliver the signal to the "easiest possible" thread should there be differences in ease of delivery between different threads.

Do manual signal(7) em um sistema Linux:

A signal may be generated (and thus pending) for a process as a whole (e.g., when sent using kill(2)) or for a specific thread (e.g., certain signals, such as SIGSEGV and SIGFPE, generated as a consequence of executing a specific machine-language instruction are thread directed, as are signals targeted at a specific thread using pthread_kill(3)). A process-directed signal may be delivered to any one of the threads that does not currently have the signal blocked. If more than one of the threads has the signal unblocked, then the kernel chooses an arbitrary thread to which to deliver the signal.

E em pthreads(7) :

Threads have distinct alternate signal stack settings. However, a new thread's alternate signal stack settings are copied from the thread that created it, so that the threads initially share an alternate signal stack (fixed in kernel 2.6.16).

Do manual pthreads(3) em um sistema OpenBSD (como um exemplo de uma abordagem alternativa):

Signals handlers are normally run on the stack of the currently executing thread.

(atualmente não estou ciente de como isso é tratado quando vários encadeamentos estão sendo executados simultaneamente em uma máquina com vários processadores)

A implementação mais antiga do LinuxThread de threads POSIX permitia apenas que threads únicos distintos fossem direcionados por sinais. De pthreads(7) em um sistema Linux:

LinuxThreads does not support the notion of process-directed signals: signals may be sent only to specific threads.