1) O manipulador de sinal é executado na próxima vez que o processo de destino retorna do modo kernel para o modo de usuário.
Isso ocorre quando o processo está agendado para ser executado novamente após uma interrupção de hardware (e já não estava em execução no modo kernel) ou quando o processo retorna de uma chamada de sistema (em algumas arquiteturas, essas são a mesma coisa ).
Em operação normal, ao sair do modo kernel, seu processo simplesmente retornará para a próxima instrução após o ponto em que originalmente saiu do modo de usuário.
No entanto, se um sinal estiver pendente para o seu processo, o kernel irá reescrever o contexto de seus processos de tal forma que o retorno ao modo de usuário irá para a primeira instrução do manipulador de sinal e sua pilha terá sido modificado para parecer que você tinha feito uma chamada de sub-rotina "especial" para o manipulador de sinal no ponto em que você originalmente saiu do modo de usuário (o retorno desta chamada de sub-rotina "especial" envolve fazer uma chamada de sistema para restaurar o estado original) .
Para mais detalhes, leia este , isso e isso .
Então o processo 'target' pode receber seu token de execução do Scheduler qualquer número de vezes antes que o manipulador de sinal seja finalmente executado ( se acontecer de ficar no modo kernel por algum motivo).
2) Não - o manipulador de sinal somente será executado no contexto do modo de usuário do seu processo.
3) Não são realmente quaisquer prioridades de execução em um sistema compartilhado no tempo como o Linux, a menos que você conte o valor legal de um processo, para que você possa varre algo que não está lá.
As coisas são complicadas por encadeamentos e as chamadas políticas de agendamento em tempo real, portanto, os comentários acima são válidos apenas para processos de encadeamento único executados com políticas de agendamento não em tempo real (o único tipo de processo que existia nos bons e velhos tempos : -).