Claro, ele precisa de sua própria pilha e conjunto de registros. Mas o contexto do thread que está sendo executado também é importante. Por um lado, isso controla o trabalho que é interrompido enquanto o sinal é processado.
Por exemplo, suponha que o thread A esteja segurando um bloqueio recursivo e tenha alterado alguma estrutura crítica para um estado inconsistente. Isso é bom, porque não liberará o bloqueio até que ele retorne essas estruturas a um estado consistente.
Agora, diga que o sinal interrompe o encadeamento A e o manipulador de sinal vai adquirir o bloqueio para verificar essa estrutura crítica. Obtém o bloqueio, porque é o segmento que já mantém o bloqueio e o bloqueio é recursivo. Como ele acaba de receber o bloqueio que protege a estrutura crítica, ele espera poder acessá-lo e encontrá-lo em um estado consistente. Mas, claro, está em um estado inconsistente. Boom! Você acabou de cair.
Portanto, neste caso, o manipulador de sinal deve sempre ir para um thread que nunca adquire esse bloqueio. Dessa forma, quando o manipulador de sinal adquire o bloqueio, é certo que nenhum outro código mantém esse bloqueio e, portanto, a estrutura deve estar em um estado consistente.
É comum no código multi-threaded ter um thread cuja única finalidade é capturar todos os sinais externos enviados para o programa. Ele lida com os sinais um por um, então o sinal nunca interrompe o código que pode conter um bloqueio.