Quanto tempo leva para um sinal não bloqueado ser entregue?

9
  1. Quando um processo envia um sinal para outro processo, em que circunstâncias o processo de recebimento espera até que seja reprogramado para ser executado?
  2. Em que circunstâncias o manipulador de sinal instalado é chamado imediatamente?
  3. Quanta sobrecarga o processo incorre ao levantar um sinal comparado a apenas chamar o manipulador de sinal correspondente diretamente?
por WiSaGaN 30.07.2012 в 17:03
fonte

2 respostas

5

Sobre a entrega de sinais, o TLPI declara que os sinais são "normalmente" entregues quando uma tarefa é agendada, quando alterna do modo kernel para o modo usuário ou "imediatamente" quando a tarefa já está em execução (presumivelmente "imediatamente" para acontecer, disparando uma interrupção primeiro, caso contrário, como poderia fazer isso). Bem, seja lá o que isso signifique, não é estritamente obrigatório, mas está muito próximo do que acontece.

Você tem que distinguir entre sinais em tempo real e "normais", assim como entre sinais "normais" que são gerados de forma síncrona, na maioria das vezes devido a um evento de hardware (por exemplo, falha de segmentação) e aqueles que não são re genereated de forma assíncrona).

Sinais em tempo real são enfileirados , sinais normais não são . Isso significa que a implementação de sinais normais provavelmente é algo como uma palavra por tarefa que serve como bitmask.
Gerar um sinal "normal" significa definir um bit, e quando o sistema operacional decide se um sinal precisa ser enviado, ele testa a palavra em relação a zero e, se necessário, descobre qual bit (s) foi definido e chama o manipulador de sinal (s), se houver, em conformidade.
A única razão prática pela qual alguém precisa saber disso é porque é possível "perder" sinais. Se dois ou mais sinais são gerados antes do primeiro ser entregue, ainda assim é apenas um sinal.

A implementação de sinais em tempo real (que são necessários para fazer fila em um tamanho dependente da implementação) é obviamente muito mais complicada.

Sinais que acontecem por causa de um evento de hardware (por exemplo, segfault) são gerados de forma síncrona, da mesma forma como se o processo chamado kill em si (capítulo 22.4 TLPI), ou seja, eles são entregues "imediatamente", por duas razões . Primeiro, não faz sentido fazer outra coisa e, segundo, já existe uma troca kernel / user quando o manipulador de armadilhas retorna. Então, a entrega é sempre "imediatamente" de qualquer maneira.

    
por Damon 30.07.2012 / 17:40
fonte
0

Basicamente, os sinais são assíncronos. Eles dependem de manipuladores de sinais para executar código quando um sinal é recebido porque você nunca sabe quando isso ocorrerá devido a fatores como o agendador de processos. A latência do envio de um sinal é baseada na interrupção de hardware / software, que é baseada na velocidade do clock.

Se você quiser descobrir como algo é implementado no Linux, verifique os padrões POSIX .

Ótima informação sobre sinais:

link

  

Quando um sinal é gerado, ele se torna pendente . Normalmente permanece   pendente por um curto período de tempo e depois é entregue ao   processo que foi sinalizado. No entanto, se esse tipo de sinal é   atualmente bloqueado , pode permanecer pendente indefinidamente - até sinais   desse tipo são desbloqueadas . Uma vez desbloqueado, será entregue   imediatamente.

Outro trecho:

  

Quando o sinal é entregue, seja imediatamente ou após um longo   atraso, a ação especificada para esse sinal é tomada.

    
por Alex W 30.07.2012 / 17:09
fonte