Os sinais gerados por software podem ser processados apenas durante interrupções de relógio?

Resposta do DeepSeek-R1

Análise profunda concluída em 52 segundos, com pesquisa em 23 artigos

Sinais não relacionados a hardware (como os gerados por software) não são limitados ao momento das interrupções de relógio para executar suas funções de tratamento. O momento de execução das funções de tratamento de sinal depende da transição do processo do modo kernel para o modo usuário, independentemente de serem disparados por interrupções, chamadas de sistema ou exceções.

Mecanismo detalhado:

• Ponto de transição entre modos: Quando um processo retorna do modo kernel para o modo usuário, o sistema operacional verifica a fila de sinais pendentes. Se houver sinais pendentes (incluindo os de software), as funções de tratamento correspondentes são chamadas. Interrupções de relógio (um tipo de interrupção de hardware) pode causar entrada no modo kernel, mas é apenas um dos pontos de disparo, não o único para o tratamento de sinais.
• Outros cenários de disparo:
• Após conclusão de chamadas de sistema (como leitura de arquivo ou operações de rede).
• Após processamento de interrupções de hardware (como interrupções de dispositivos I/O).
• Após resolução de eventos de exceção (como falhas de página ou instruções inválidas). Nesses casos, o sistema operacional executa a função de tratamento de sinal durante a transição do modo kernel para o modo usuário.
• Especialidade e limitações das interrupções de relógio: As interrupções de relógio são usadas principalmente para agendamento de fatias de tempo e tarefas temporizadas. Elas podem criar oportunidades de entrada no modo kernel indiretamente, mas o tratamento de sinais não depende delas. A latência no tratamento de sinais de software (como o SIGTERM enviado pelo comando kill) depende do último ponto de saída do modo kernel, não da frequência das interrupções de relógio.

Em resumo, o momento de execução do tratamento de sinal depende da saída do modo kernel, não de tipos específicos de interrupção.

Introdução ao Tratamento de Sinais

Manual de Programação de Sistemas Linux-UNIX

Como as funções de tratamento de sinal no modo usuário são executadas?

Modo Inteligente Resposta concluída

Análise profunda concluída em 31 segundos, com pesquisa em 20 artigos

A seguir, apresentamos o fluxo completo de execução das funções de tratamento de sinal registradas pelo processo, com base no gatilho do sinal, intervenção do kernel, gerenciamento de pilha e mecanismos de recuperação:

I. Fase de Gatilho e Intervenção do Kernel

1. Geração do Sinal

• Interrupções de hardware (como divisão por zero), exceções de chamadas de sistema ou eventos externos (como SIGINT) geram sinais.
• O kernel marca o conjunto de sinais pendentes (pending) do processo alvo e verifica seu estado de bloqueio (block).

2. Escolha do Momento de Entrega

• O kernel verifica os sinais pendentes antes da saída do modo kernel para o modo usuário.
• Se o sinal não estiver bloqueado, ele é preparado para entrega; caso contrário, permanece pendente até ser liberado.

II. Preparação para Execução da Função de Tratamento

1. Troca de Quadro de Pilha e Salvamento de Contexto

• O kernel cria temporariamente um quadro de pilha independente no espaço de pilha do usuário, salvando o contexto dos registradores (incluindo RBP, RSP, RIP etc.).
• RSP aponta para o novo topo da pilha, e o estado do quadro original é preservado com instruções como push %rbp.

2. Regra de Transferência de Controle

• Vinculação de Thread: Se o sinal for disparado por uma thread filha, a função de tratamento é executada no contexto dessa thread (princípio "quem dispara, trata").
• O kernel modifica o registrador RIP para apontar para a função de tratamento registrada pelo usuário (ex: handle_segv()).

III. Processo de Execução da Função de Tratamento

1. Execução da Função no Modo Usuário

• Após retornar ao modo usuário, o processo salta diretamente para a área de código da função de tratamento.
• A função pode acessar dados globais do processo, mas deve cuidar com o problema de "segurança de sinal assíncrono" (evitar funções não reentrantes).

2. Tratamento de Sinais Aninhados

• Se um novo sinal chegar durante a execução da função, o kernel decide se bloqueia sinais do mesmo tipo com base no campo sa_mask.

IV. Recuperação do Fluxo Original

1. Retorno ao Kernel

• A função de tratamento deve chamar explicitamente a chamada de sistema sigreturn para retornar ao modo kernel.

2. Recuperação de Contexto

• O kernel restaura o estado dos registradores (RBP, RSP, RIP) do quadro de pilha temporário.
• O quadro de pilha temporário é limpo e RSP é redefinido para o topo da pilha original.

3. Continuação do Fluxo Original

• O processo retorna ao modo usuário e continua a execução a partir da posição interrompida (ex: código na função main).

Resumo das Características Principais

Característica	Descrição
Assincronia	A função de tratamento é independente do fluxo principle, sem relação de chamada direta.
Vinculação de Thread	Em programas multithread, o tratamento de sinais é executado na thread que disparou o sinal, não compartilhado globalmente.
Controle do Kernel	Troca de pilha, salvamento e recuperação de contexto são gerenciados pelo kernel, garantindo estabilidade.
Isolamento de Segurança	Quadros de pilha independentes evitam danos ao fluxo original; sigreturn é o único caminho válido para retorno.

O fluxo de execução da função de tratamento de sinal registrado pelo processo pode ser dividido nas seguintes etapas:

I. Gatilho e Momento de Entrega do Sinal

1. Gatilho Assíncrono: Sinais são gerados por interrupções de hardware ou detecção de exceções pelo kernel, enquanto o processo pode estar executando no modo usuário ou kernel.
2. Momento de Entrega: O kernel verifica sinais não tratados antes da saída do modo kernel para o modo usuário, escolhendo esse momento para entregar o sinal (evitando interrupções em operações críticas).

II. Mecanismo de Execução da Função de Tratamento

1. Troca de Quadro de Pilha: O kernel aloca um espaço de pilha independente para a função de tratamento, separado do fluxo de execução original (ex: função main):

• Salva o estado dos registradores do processo (ex: RBP, RSP etc.).
• Altera RSP para apontar para o novo quadro de pilha, garantindo que a função não corrompa os dados da pilha original.

2. Transferência para Função de Tratamento no Modo Usuário: O kernel tranfsere o controle para a função registrada pelo usuário (ex: sighandler), onde o processo executa a lógica de tratamento.

• A função de tratamento não tem relação direta com o código original, sendo um fluxo de controle independente.
• Em programas multithread, segue o princípio "quem dispara, trata" (ex: SIGSEGV disparado por uma thread filha é tratado por essa thread).

III. Processo de Retorno e Recuperação

1. Retorno da Função: Após a conclusão da função de tratamento, ela chama implicitamente a chamada de sistema sigreturn para retornar ao modo kernel.
2. Recuperação de Contexto: O kernel restaura o estado dos registradores salvos e continua o fluxo original (ex: retorno à função main).

IV. Pontos de Projeto Importantes

• Assincronia: A função de tratamento de sinal não tem relação direta com o código original, sendo um fluxo de controle independente.
• Localidade de Thread: Em programas multithread, a função de tratamento de sinal está vinculada à thread que disparou o sinal, não globalmente ao processo.
• Segurança Gerenciada pelo Kernel: A troca de pilha e o salvamento/restauração de contexto são gerenciados pelo kernel, evitando erros causados por operações do usuário.

I. Momento de Entrega do Sinal

1. Verificação Antes da Saída do Modo KernelAntes de retornar ao modo usuário após chamadas de sistema, interrupções ou exceções, o kernel verifica sinais não tratados.
2. Mecanismo de Gatilho AssíncronoSinais são disparados por interrupções de hardware (ex: Ctrl+C), erros de memória (SIGSEGV) ou chamadas de sistema kill(), independentemente do fluxo de execução do processo.

II. Execução da Função de Tratamento

1. Intervenção do Kernel na Troca de PilhaO kernel aloca um espaço de pilha independente para a função de tratamento, isolado do fluxo original (ex: main):

• Salva os registradores do processo (ex: RSP, RIP etc.)13;
• Altera RSP para apontar para o novo quadro de pilha, garantindo que a função não corrompa os dados da pilha original1.

1. Transição para Função de Tratamento no Modo UsuárioO kernel transfere o controle para a função registrada pelo usuário (ex: sighandler), onde o processo executa a lógica de tratamento34.

• A função de tratamento não tem relação direta com o código original, sendo um fluxo de controle independente3;
• Em programas multithread, segue o princípio "quem dispara, trata" (ex: SIGSEGV disparado por uma thread filha é tratado por essa thread)2.

III. Retorno e Recuperação da Função

1. Retorno ao Kernel via sigreturnApós o término da função de tratamento, ela automaticamente chama a chamada de sistema sigreturn para retornar ao modo kernel35.
2. Recuperação do Contexto OriginalO kernel restaura os registradores salvos (ex: RSP, RIP etc.), continuando com o fluxo original (ex: função main)56.

IV. Pontos Importantes do Projeto

• Duas Mudanças de Modo：Necessita passar por uma sequência completa de mudanças de modo: usuário → kernel → usuário (função de tratamento) → kernel → usuário.
• Localidade de Thread：Em programas multithread, o tratamento de sinais está vinculado à thread que disparou o sinal, não globalmente ao processo.
• Segurança Gerenciada pelo Kernel：A troca de pilha e o salvamento/restauração de contexto são gerenciados pelo kernel, evitando erros causados por operações do usuário.

Os processos filhos herdam os tratadores de sinal do processo pai?

Modo Inteligente Resposta concluída

Pesquisa em 26 artigos

No sistema Linux, os processos filhos herdam os tratadores de sinal do processo pai, mas existem algumas exceções. Abaixo estão as regras-chave e considerações:

I. Regras de Herança de Tratadores de Sinal

1. Herança PadrãoQuando um processo filho é criado via fork(), ele copia a tabela de tratadores de sinal do processo pai (incluindo funções personalizadas e comportamentos padrão). Por exemplo:

// Configuração de tratador de sinal no processo pai
signal(SIGINT, handler);  // O processo filho herda esse tratador

2. Exceções‌

• Após chamada de sistema execve(): Ao executar um novo programa, todos os tratadores de sinal não ignoradso (não SIG_IGN) são redefinidos para o comportamento padrão, mas os sinais configurados para ignorar (SIG_IGN) permanecem ignorados4.
• Tratamento de sinal em threads: Em ambientes multithread, todos os threads compartilham os mesmos tratadores de sinal4.

II. Exemplo de Verificação

#include
#include
#include

void handler(int sig) {
printf("Recebido sinal %d (PID: %d)\n", sig, getpid());
}

int main() {
signal(SIGINT, handler);  // Configuração de tratador no processo pai
pid_t pid = fork();
if (pid == 0) {  // Processo filho
raise(SIGINT);  // Gera sinal no processo filho, chamando o tratador herdado
} else {
wait(NULL);  // Processo pai espera pelo filho
}
return 0;
}

Após a execução, o processo filho gera SIGINT e imprime informações de sinal, comprovando a herança5.

III. Considerações de Cenários Especiais

1. Máscara de Sinal Herdada
   O processo filho herda a máscara de sinal bloqueada (como definido por SIG_BLOCK), mas pode modificá-la com pthread_sigmask4.
2. Processos em Segundo Plano e Sinais de Terminal
   Processos em segundo plano podem receber SIGTTIN ao ler dados do terminal, e se não forem tratados, podem causar falhas de segmentação4.

Conclusão

O processo filho herda por padrão os tratadores de sinal do processo pai, mas é importante observar as regras de redefinição após execve() e a característica de compartilhamento em threads. Na prática, pode-se gerenciar os comportamentos de sinal usando comandos trap ou signal.

O shell do Linux (como o Bash) reescreve os tratadores de alguns sinais por padrão para adaptar-se ao ambiente interativo ou às necessidades de controle de scripts. Abaixo está um resumo dos sinais-chave e de seus comportamentos de tratamento:

I. Tratadores de Sinais Reescritos pelo Shell

1. **SIGINT (2)**‌

   • Comportamento Padrão‌：Finaliza o grupo de processos foreground (ex: Ctrl+C).
   • Reescrita pelo Shell‌：O shell interativo captura e passa SIGINT aos processos filhos, mas scripts podem personalizar o tratamento com trap57.

2. **SIGQUIT (3)**‌

   • Comportamento Padrão‌：Finaliza o processo e gera um arquivo de despejo de memória.
   • Reescrita pelo Shell‌：O shell interativo ignora esse sinal por padrão, evitando saídas acidentais58.

3. **SIGTERM (15)**‌

   • Comportamento Padrão‌：Solicita que o processo termine normalmente.
   • Reescrita pelo Shell‌：O shell interativo ignora por padrão, mas scripts podem capturar com trap para saídas elegantes512.

4. **SIGHUP (1)**‌

   • Comportamento Padrão‌：Finaliza o processo quando o terminal é desconectado.
   • Reescrita pelo Shell‌：O shell passa esse sinal a todos os processos filhos e sai por padrão57.

5. **SIGTSTP (20)**‌

   • Comportamento Padrão‌：Pausa o processo foreground (ex: Ctrl+Z).
   • Reescrita pelo Shell‌：O shell gerencia o controle de jobs, registrando o estado dos processos pausados78.

II. Sinais que Não Podem Ser Reescritos

• SIGKILL (9) e SIGSTOP (19)
  O kernel os trata forçosamente, nenhum processo (incluindo o shell) pode capturar ou ignorá-los14.

III. Comparação do Mecanismo de Tratamento de Sinais

Sinal	Comportamento Padrão do Kernel	Comportamento Padrão do Shell	Personalização Possível
SIGINT	Finaliza o processo	Passa para o processo filho ou captura	Sim (com trap)514
SIGQUIT	Finaliza e gera despejo	Ignora	Sim58
SIGTERM	Finaliza o processo	Ignora (scripts podem capturar)	Sim512
SIGHUP	Finaliza o processo	Passa o sinal e sai	Parcial57

IV. Tratamento de Sinais Personalizado pelo Usuário

Usando o comando trap, é possível substituir o comportamento padrão do shell, por exemplo:

trap 'echo "Capturado SIGINT"; exit' SIGINT  # Tratamento personalizado de SIGINT
trap '' SIGTERM                        # Ignora SIGTERM

Essa mecanica permite que scripts realizem limpeza de recursos ou responda a eventos assíncronos.

Os sinais gerados por interrupções de hardware são entregues ao shell ou ao processo foreground?

Modo Inteligente Resposta concluída

Pesquisa em 27 artigos

Os sinais gerados por interrupções de hardware (como Ctrl+C gerando SIGINT) são entregues ao processo foreground, não ao próprio shell. Abaixo está a análise detalhada do mecanismo:

I. Fluxo de Entrega de Sinais

1. Gatilho de Interrupção de Hardware‌ Quando o usuário pressiona Ctrl+C, o teclado gera uma interrupção de hardware, que o CPU captura e o kernel traduz em sinal SIGINT13.
2. Processamento do Kernel e Localização do Destino‌ O kernel determina o destinatário com base no grupo de processos foreground (Foreground Process Group) e escreve o sinal no PCB (Block de Controle de Processo) do processo13.
3. Papel do Shell como Mediador‌ O shell apenas gerencia grupos de processos (como iniciar tarefas foreground/background), não trata sinais diretamente. Os sinais são entregues diretamente ao processo foreground57.

II. Comparação de Cenários

Cenário	Destinatário do Sinal	Explicação
Processo foreground	Processo foreground	Recebe SIGINT por padrão (finaliza o processo)13
Processo background	Não recebe por padrão	Precisa habilitar o controle de jobs com trap ou set -m para capturar sinais711
Script shell	Próprio shell	Se o script roda como foreground, o sinal pode ser capturado pelo trap do script912

III. Princípio Técnico

1. Mecanismo de Grupo de Processos‌ O Linux usa grupos de processos para gerenciar tarefas, e os sinais de interrupção de hardware são enviados ao grupo de processos foreground (o grupo de processos atualmente interativo)36.
2. Processamento Assíncrono‌ A entrega de sinais é assíncrona, e o kernel interrompe forçosamente o código do processo foreground no modo usuário para priorizar o tratamento do sinal48.

IV. Comportamento Personalizado pelo Usuário

Usando o comando trap, é possível substituir o comportamento padrão, por exemplo:

trap 'echo "Capturado SIGINT"; exit' SIGINT  # Tratamento personalizado no processo foreground

Mas essa operação ainda ocorre no contexto do processo foreground, sem envolvimento direto com o shell912.

Conclusão

Os sinais de interrupção de hardware são entregues ao processo foreground, e o shell atua apenas como gerente de grupos de processos, sem participar diretamente do tratamento de sinais13. Se o shell precisar responder a sinais, precisa chamar explicitamente.

Resposta do DeepSeek-R1

Pesquisa em 29 artigos

No sistema Linux, quando múltiplos sinais chegam simultaneamente, a ordem de execução segue as seguintes regras:

1. **Prioridade dos Sinais em Tempo Real (Sinais Confiáveis)**‌

   • Para diferentes sinais em tempo real (números 34 e acima), o sinal com valor menor tem prioridade mais alta e é entregue primeiro46.
   • Vários instâncias do mesmo sinal são colocadas em fila e processadas na ordem de envio414.

2. **Prioridade dos Sinais Não Em Tempo Real (Sinais Não Confiáveis)**‌

   • Quando múltiplos sinais não em tempo real (números 1~31) chegam simultaneamente, os sinais relacionados a hardware (como SIGSEGV, SIGFPE) são priorizados, seguidos pelos sinais com menor número1415.
   • Várias instâncias do mesmo sinal não em tempo real são combinadas em uma única execução46.

3. Cenário de Mistura de Sinais em Tempo Real e Não Em Tempo Real‌

   • Se sinais em tempo real e não em tempo real estiverem pendentes, o sistema Linux normalmente entrega primeiro os sinais não em tempo real14.

4. Sinais Especiais‌

   • SIGKILL (9) e SIGSTOP (19) não podem ser capturados, ignorados ou bloqueados, terminando ou pausando o processo imediatamente, com a maior prioridade15.

Ordem de Execução Resumida：
SIGKILL/SIGSTOP > Sinais não em tempo real relacionados a hardware > Outros sinais não em tempo real (por número crescente) > Sinais em tempo real (por número crescente)

Resposta do DeepSeek-R1

Pesquisa em 26 artigos

Os sinais em tempo real são chamados de sinais confiáveis devido às seguintes características de design:

1. Mecanismo de Gerenciamento por Fila‌
   Os sinais em tempo real (números 3264) suportam fila, e quando múltiplos sinais iguais chegam, o kernel os armazena na ordem de chegada e os entrega sequencialmente, sem perder instâncias. Os sinais não em tempo real (131) combinam sinais repetidos, mantendo apenas uma instância35.
2. Garantia de Prioridade e Ordem‌
   Diferentes sinais em tempo real são processados na ordem crescente de número (número menor tem maior prioridade), e sinais iguais são processados na ordem FIFO. Essa ordem determinística evita problemas de desordem dos sinais não em tempo real1213.
3. Capacidade de Transmissão de Dados‌
   Ao enviar sinais em tempo real com sigqueue(), é possível incluir dados adicionais (como inteiro ou ponteiro), e o receptor obtém informações completas através da estrutura siginfo_t. Os sinais não em tempo real não têm essa funcionalidade7.
4. Garantia de Confiabilidade no Nível do Kernel‌
   O registro, entrega e processamento dos sinais em tempo real são mantidos pelo kernel, garantindo a integridade do ciclo de vida do sinal, resolvendo problemas de perda ou reset de comportamento dos sinais não confiáveis anteriores25.

Resumo: A fila, ordem, capacidade de transmissão de dados e garantia no nível do kernel dos sinais em tempo real os tornam sinais confiáveis para comunicação de tarefas críticas.

Modo Inteligente Resposta concluída

Pesquisa em 40 artigos

As diferenças na implementação de pause() e sleep() estão principalmente nos seguintes aspectos:

1. Mecanismo de Agendamento no Kernel‌

• pause(): Define o estado do processo como TASK_INTERRUPTIBLE e o remove da fila de execução, dependendo totalmente de sinais para despertar. Se nenhum sinal for recebido, o processo dorme permanentemente89.
• sleep(): Usa temporizador no kernel (como schedule_timeout()) para controlar o tempo de espera, e o estado do processo pode ser TASK_INTERRUPTIBLE ou TASK_UNINTERRUPTIBLE, podendo ser despertado por tempo ou sinal921.

2. Condições de Despertar‌

• pause(): Apenas responde a interrupções de sinal (como SIGCONT), sem parâmetro de tempo, retornando -1 (errno=EINTR) após interrupção por sinal18.
• sleep(): Tempo ou sinal podem despertar o processo, retornando o tempo restante, permitindo o processamento do ciclo de espera não concluído68.

3. Dependência de Implementação‌

• pause(): Chama diretamente a chamada de sistema sys_pause(), sem parâmetro de tempo, apenas dependendo do mecanismo de tratamento de sinais920.
• sleep(): Geralmente implementado via nanosleep(), com o kernel usando temporizador de alta precisão (como hrtimer) para gerenciar o tempo de espera920.

4. Cenários de Aplicação‌

• pause(): Usado para sincronização entre processos (como esperar sinal de filho), enfatizando controle por eventos622.
• sleep(): Usado para tarefas temporizadas ou atrasos, enfatizando controle de tempo721.

5. Comportamento de Tratamento de Sinal‌

• pause(): Se a função de tratamento de sinal for chamada, pause() retorna imediatamente, sem restaurar automaticamente o tempo de espera16.
• sleep(): Se interrompido por sinal, pode julgar o tempo restante com base no retorno, permitindo reiniciar o tempo de espera823.

Resumo: pause() é uma espera sem limite de tempo baseada em sinal, enquanto sleep() é um tempo de espera interrompível, diferindo essencialmente em agendamento no kernel, condições de despertar e objetivos de aplicação.

DS-V3 Resposta concluída

No sistema Unix/Linux, o mecanismo de bloqueio automático de sinais (Automatic Signal Blocking) refere-se à interrompção temporária de certos sinais pelo kernel para evitar condições de corrida (race conditions) ou chamadas recursivas durante o processamento de sinais. Abaixo está uma explicação detalhada:

1. Condições de Disparo do Bloqueio Automático‌

Quando um processo está executando o tratador de sinal (signal handler), o kernel normalmente adiciona esse sinal ao conjunto de máscara de sinal (signal mask) do processo, bloqueando-o durante a execução. Esse mecanismo é usado principalmente para:

• Evitar chamadas recursivas do tratador de sinal (por exemplo, o tratador de SIGINT não termina quando SIGINT é recebido novamente).
• Garantir a atomicidade do tratador de sinal (evitar interrupções em segmentos críticos de código).

2. Alcance do Bloqueio Automático‌

• Apenas afeta o sinal atualmente sendo processado (por exemplo, SIGINT é bloqueado durante a execução do tratador de SIGINT).
• Não afeta outros sinais (a menos que sejam manualmente configurados com sigprocmask ou sigaction com sa_mask).
• Válido apenas durante a execução do tratador de sinal, sendo restaurado automaticamente após a conclusão.

**3. Como Controlar o Comportamento de Bloqueio Automático?**‌

(1) Usando sigaction para Configurar Tratador de Sinal‌

A estrutura struct sigaction permite controle mais fino do comportamento de bloqueio de sinais:

#include <signal.h>

void handler(int sig) {
    // Lógica de tratamento de sinal
}

int main() {
    struct sigaction sa;
    sa.sa_handler = handler;
    sigemptyset(&sa.sa_mask);  // Limpa o conjunto de sinais bloqueados
    sa.sa_flags = 0;           // Comportamento padrão (bloqueio automático do sinal atual)

    sigaction(SIGINT, &sa, NULL);  // Registra o tratador de SIGINT
    while (1) pause();  // Espera por sinal
    return 0;
}

• sa.sa_mask: Pode especificar sinais adicionais a serem bloqueados durante a execução do tratador (mesmo que não sejam automaticamente bloqueados).
• sa.sa_flags:
• SA_NODEFER (ou SA_NOMASK): Desativa o bloqueio automático, permitindo que o sinal seja chamado recursivamente.
• SA_RESTART: Faz com que certas chamadas de sistema sejam automaticamente reiniciadas após o tratador de sinal.

**(2) Usando signal() (método mais antigo, comportamento pode variar)**‌

#include

void handler(int sig) {
// Lógica de tratamento de sinal
}

int main() {
signal(SIGINT, handler);  // Registra o tratador de SIGINT
while (1) pause();
return 0;
}

• Em sistemas Unix mais antigos, o comportamento de signal() pode variar:
  • Alguns implementam o bloqueio automático do sinal atual (como sigaction por padrão).
  • Outros não bloqueiam automaticamente (podendo causar chamadas recursivas).
• Recomenda-se usar sigaction, pois oferece maior controle.

4. Resumo Importante‌

Comportamento	Explicação
Bloqueio Automático Padrão	Durante a execução do tratador de sinal, o kernel bloqueia temporariamente o sinal (para evitar recursão).
Restauração da Máscara Original	Após o tratador terminar, a máscara de sinal é restaurada automaticamente (o bloqueio temporário é removido).
Bloqueio Manual Adicional	Pode-se bloquear sinais adicionais durante a execução do tratador com sa_mask.
Desativação do Bloqueio Automático	Usando o sinal SA_NODEFER, permite que o sinal seja chamado recursivamente.

5. Exemplo: Teste de Sinais Recursivos‌

#include <stdio.h>
#include <signal.h>
#include <unistd.h>

void handler(int sig) {
    printf("Capturado sinal %d\n", sig);
    sleep(1);  // Simula processamento longo
}

int main() {
    struct sigaction sa;
    sa.sa_handler = handler;
    sigemptyset(&sa.sa_mask);
    sa.sa_flags = 0;  // Bloqueio automático padrão do sinal atual

    sigaction(SIGINT, &sa, NULL);

    printf("Pressione Ctrl+C para testar...\n");
    while (1) pause();

    return 0;
}

• Resultado do teste：
• Se pressionar várias vezes Ctrl+C rapidamente, apenas o primeiro SIGINT será processado imediatamente, os subsequentes serão bloqueados até que o tratador termine.
• Se definir sa.sa_flags = SA_NODEFER, o SIGINT pode ser chamado recursivamente pelo tratador.

6. Conclusão‌

• Por padrão, o tratador de sinal bloqueia automaticamente o sinal durante sua execução, evitando chamadas recursivas.
• O bloqueio é automaticamente removido após o tratador terminar, restaurando a máscara de sinal original.
• Pode-se ajustar o comportamento de bloqueio com sa_mask e sa_flags no sigaction.

Espero que essa explicação ajude a entender completamente o mecanismo de bloqueio automático de sinais! Se tiver dúvidas, sinta-se à vontade para perguntar.