Señal del proceso de aprendizaje gráfico de 10.000 palabras de Linux

1. Concepto de señal

Las señales son una forma de notificación asincrónica de eventos entre procesos y son interrupciones suaves.

1.1 En Linux, solemos usar Ctrl+c para finalizar un proceso en primer plano.

• 1. La señal generada por Ctrl-C solo se puede enviar al proceso de primer plano. Agregar un & después de un comando puede ejecutarlo en segundo plano, de modo que Shell pueda aceptar nuevos comandos e iniciar nuevos procesos sin esperar a que finalice el proceso.
• 2. Shell puede ejecutar un proceso en primer plano y cualquier número de procesos en segundo plano al mismo tiempo. Solo el proceso en primer plano puede recibir señales generadas por teclas de control como Ctrl-C.
• 3. Cuando el proceso en primer plano se está ejecutando, el usuario puede presionar Ctrl-C en cualquier momento para generar una señal, es decir, el código de espacio de usuario del proceso puede recibir la señal SIGINT y terminar dondequiera que se ejecute, por lo que el La señal es relativa al proceso y el flujo de control es asíncrono.

2. Señales comunes

Utilice el comando kill -l para ver la lista de señales definidas por el sistema

• Cada señal tiene un número y un nombre de definición de macro. Estas definiciones de macro se pueden encontrar en signal.h
• Los números 34 y superiores son señales en tiempo real.
• Las condiciones bajo las cuales se generan estas señales y cuáles son las acciones de procesamiento predeterminadas se detallan en la señal (7): señal man 7

3. Naturaleza de la señal

        Las señales son interrupciones de software, que son una simulación del mecanismo de interrupción a nivel de software . En principio, un proceso que recibe una señal es lo mismo que un procesador que recibe una solicitud de interrupción. Las señales son asíncronas y un proceso no tiene que esperar la llegada de la señal mediante ninguna operación, de hecho, el proceso no sabe cuándo llega la señal.

        Las señales son el único mecanismo de comunicación asincrónico entre los mecanismos de comunicación entre procesos . Pueden considerarse notificaciones asincrónicas, notificando al proceso que recibe las señales lo que ha sucedido. Después de la extensión POSIX en tiempo real, el mecanismo de señal se vuelve más poderoso y, además de la función de notificación básica, también puede entregar información adicional.

4. Fuente de señal

4.1 Generar señales a través de teclas de terminal.

La acción de procesamiento predeterminada de SIGINT es finalizar el proceso y la acción de procesamiento predeterminada de SIGQUIT es finalizar el proceso y el volcado de núcleo.

4.1.1 ¿Qué es el volcado de memoria?

Cuando un proceso está a punto de finalizar anormalmente, puede optar por guardar todos los datos de la memoria del espacio de usuario del proceso en el disco. El nombre del archivo suele ser core, lo que se denomina Core Dump. La terminación anormal del proceso generalmente se debe a errores, como el acceso ilegal a la memoria que provoca fallas de segmentación. Puede usar un depurador para verificar el archivo principal posteriormente y descubrir la causa del error. Esto se llama depuración post-mortem. El tamaño del archivo central que un proceso puede generar depende del límite de recursos del proceso (esta información se almacena en la PCB). De forma predeterminada, no se permite generar archivos principales porque los archivos principales pueden contener información confidencial, como contraseñas de usuario, y no son seguros.

Durante la fase de desarrollo y depuración, puede utilizar el comando ulimit para cambiar este límite y permitir que se generen archivos principales. Primero, use el comando ulimit para cambiar el límite de recursos del proceso Shell  $ ulimit -c 1024  para permitir que el archivo principal tenga hasta 1024K

        

 

4.1.2 Captura de señal de los botones del terminal 

#include <stdio.h>
#include <signal.h>
int count = 0;
void handler(int sig)
{
    printf("the catched count is %d  ",++count);

    printf("catch a sig : %d\n", sig);
}
int main()
{
    signal(2, handler); // 信号是可以被自定义捕捉的，siganl函数就是来进行信号捕捉的

    while (1)
        ;
    return 0;
}

4.2 Llamar a funciones del sistema para enviar señales al proceso

Las muertes de uso común incluyen pkill y killall, etc.

El comando matar se implementa llamando a la función matar. La función kill puede enviar una señal específica a un proceso específico. La función de aumento puede enviar una señal específica al proceso actual (enviarse una señal a sí misma).

#include <signal.h>
int kill(pid_t pid, int signo);
int raise(int signo);
这两个函数都是成功返回0,错误返回-1。

#include <stdlib.h>
void abort(void);
就像exit函数一样,abort函数总是会成功的,所以没有返回值。
abort函数使当前进程接收到信号而异常终止。

4.3 Señales generadas por las condiciones del software.

SIGPIPE es una señal generada por las condiciones del software: en la tubería, el extremo de lectura se cierra y el extremo de escritura sigue escribiendo.

Broken pipe: write to pipe with no readers.
管道破裂。这个信号通常在进程间通信产生，比如采用FIFO(管道)通信的两个进程，
读管道没打开或者意外终止就往管道写，
写进程会收到SIGPIPE信号。此外用Socket通信的两个进程，
写进程在写Socket的时候，读进程已经终止。

#include <unistd.h>
unsigned int alarm(unsigned int seconds);
调用alarm函数可以设定一个闹钟,也就是告诉内核在seconds秒之后给当前进程发SIGALRM信号, 该信号的默认处理动作是终止当前进程。
可以重复设置，新的会覆盖旧的并返回上次闹钟剩余的时间，可以设置为0，意思就是取消闹钟，并返回上次闹钟剩余的时间

4.4 La excepción de hardware genera señal

Las excepciones de hardware son detectadas de alguna manera por el hardware y notificadas al kernel, que luego envía las señales apropiadas al proceso actual. Por ejemplo, si el proceso actual ejecuta la instrucción de dividir por 0 , la unidad aritmética de la CPU generará una excepción y el núcleo interpretará esta excepción como una señal SIGFPE y la enviará al proceso. Para otro ejemplo, si el proceso actual accede a una dirección de memoria ilegal (puntero salvaje) , la MMU generará una excepción y el núcleo interpretará esta excepción como una señal SIGSEGV y la enviará al proceso.

4.4.1 Captura de señales generadas por excepciones de hardware

Y después de la excepción de hardware, el programa no continuará ejecutándose.

#include <stdio.h>
#include <signal.h>
#include <unistd.h>
#include <stdlib.h>
int count = 0;
int count2=0;
void handler(int sig)
{
    printf("the catched count is %d count2:%d ",++count,count2);

    printf("catch a sig : %d\n", sig);
}
int main()
{
    signal(11, handler); // 信号是可以被自定义捕捉的，siganl函数就是来进行信号捕捉的

    while (1){
        sleep(1);
        count2++;
        int *p=NULL;
        *p=100;
    }
    return 0;
}

5. Clasificación de señales

1. Señales confiables y señales no confiables

Señales poco fiables:

El mecanismo de señal de Linux se hereda básicamente de los sistemas Unix. El mecanismo de señal en los primeros sistemas Unix era relativamente simple y primitivo, y luego expuso algunos problemas en la práctica, por lo que las señales basadas en el mecanismo inicial se denominaron "señales no confiables" y el valor de la señal era menor que SIGRTMIN (en Red Hat 7.2). , SIGRTMIN =32, SIGRTMAX=63) son señales no confiables .

Los principales problemas con señales poco confiables son:

• Cada vez que un proceso maneja una señal, la respuesta a la señal se establece como la acción predeterminada . En algunos casos, esto resultará en un manejo incorrecto de la señal; por lo tanto, si el usuario no desea dicha operación, debe llamar a signal() nuevamente al final de la función de procesamiento de señal para reinstalar la señal.
• Es posible que se pierda la señal (más sobre esto más adelante). Si la señal ocurre varias veces cuando el proceso está procesando una señal y las señales posteriores de este tipo no están en cola, entonces la señal solo se transmite una vez , es decir, se produce una pérdida de señal.
  Por lo tanto, las señales no confiables en los primeros Unix se refieren principalmente a procesos que pueden responder incorrectamente a señales y señales que pueden perderse.

Linux admite señales no confiables, pero ha realizado mejoras en el mecanismo de señales no confiables: después de llamar a la función de procesamiento de señales, no es necesario volver a llamar la función de instalación de señales (la función de instalación de señales se implementa en el mecanismo confiable). Por lo tanto, el problema de las señales poco confiables en Linux se refiere principalmente a la posible pérdida de señales .

señal confiable

Las señales con valores de señal entre SIGRTMIN y SIGRTMAX son señales confiables y las señales confiables superan el problema de una posible pérdida de señal . Si bien Linux admite la nueva versión de la función de instalación de señales sigation() y la función de envío de señales sigqueue(), todavía admite la función de instalación de señales signal() temprana y la función de envío de señales kill().

       Nota: No tenga este malentendido: la señal enviada por sigqueue() e instalada por sigaction es confiable. De hecho, una señal confiable se refiere a una nueva señal agregada más tarde (el valor de la señal está entre SIGRTMIN y SIGRTMAX); una señal no confiable es una señal con un valor de señal menor que SIGRTMIN . La confiabilidad o falta de confiabilidad de una señal solo está relacionada con el valor de la señal y no tiene nada que ver con las funciones de envío e instalación de la señal. Actualmente, la señal () en Linux se implementa a través de la función sigation (), por lo que incluso si la señal se instala a través de la señal (), no es necesario volver a llamar a la función de instalación de la señal al final de la función de procesamiento de la señal. Al mismo tiempo, las señales en tiempo real instaladas por signal() admiten colas y no se perderán.

       Para las dos funciones de instalación de señales actuales de Linux: signal() y sigaction(), no pueden convertir la señal antes de SIGRTMIN en una señal confiable (ninguna admite la cola, aún puede perderse y sigue siendo una señal no confiable). , se admiten colas para señales después de SIGRTMIN . La mayor diferencia entre estas dos funciones es que las señales instaladas a través de sigaction pueden pasar información a la función de procesamiento de señales (esto es cierto para todas las señales), mientras que las señales instaladas a través de señales no pueden pasar información a la función de procesamiento de señales. Lo mismo ocurre con las funciones de señalización.

6. Métodos comunes de procesamiento de señales.

• 1. Ignore esta señal.
• 2. Ejecute la acción de procesamiento predeterminada de la señal.
• 3. Proporcione una función de procesamiento de señales y requiera que el kernel cambie al modo de usuario para ejecutar la función de procesamiento al procesar la señal. Este método se denomina captar una señal.

7. Función de operación del conjunto de señales

7.1 Algunos conceptos relacionados con señales

• La ejecución real de la acción de procesamiento de señales se denomina entrega de señales (Entrega)
• El estado entre la generación y entrega de la señal se llama señal pendiente .
• Un proceso puede optar por bloquear una señal.
• La señal bloqueada permanecerá en estado pendiente cuando se genere y la acción de entrega no se ejecutará hasta que el proceso desbloquee la señal.
• Tenga en cuenta que bloquear e ignorar son diferentes: mientras la señal esté bloqueada, no se entregará, mientras que ignorar es una acción de procesamiento opcional después de la entrega.

7.2 Representación de señales en el kernel.

• Cada señal tiene dos bits de bandera que indican bloqueo y pendiente, y un puntero de función que indica la acción de procesamiento. Cuando se genera una señal, el kernel establece el indicador pendiente de la señal en el bloque de control de proceso y no borra el indicador hasta que se entrega la señal. En el ejemplo anterior, la señal SIGHUP no se bloquea ni se genera, y la acción de procesamiento predeterminada se realiza cuando se entrega.
• La señal SIGINT se ha generado, pero está bloqueada, por lo que no se puede entregar temporalmente. Aunque su acción de procesamiento es ignorar, esta señal no se puede ignorar antes de desbloquear, porque el proceso todavía tiene la oportunidad de cambiar la acción de procesamiento y luego desbloquear.
• La señal SIGQUIT nunca se ha generado. Una vez que se genera la señal SIGQUIT, se bloqueará. Su acción de procesamiento es la función singhandler definida por el usuario. ¿Qué sucede si una señal se genera varias veces antes de que el proceso la desbloquee? POSIX.1 permite que el sistema entregue la señal una o más veces. Linux implementa esto: las señales regulares que se generan varias veces antes de la entrega se cuentan solo una vez, mientras que las señales en tiempo real que se generan varias veces antes de la entrega se pueden colocar en una cola en secuencia. Tenga en cuenta que las señales en tiempo real no se analizan aquí. 

7.3 sigset_t

De la figura anterior, cada señal tiene solo un bit de bandera pendiente, que es 0 o 1. No registra cuántas veces se genera la señal.La bandera de bloqueo también se expresa de esta manera. Por lo tanto, las banderas pendientes y bloqueadas se pueden almacenar con el mismo tipo de datos sigset_t. sigset_t se llama conjunto de señales. Este tipo puede representar el estado "válido" o "no válido" de cada señal, y "válido" e "inválido" en el conjunto de señales de bloqueo " .

El conjunto de señales de bloqueo también se denomina máscara de señal del proceso actual. La " máscara" aquí debe entenderse como bloqueo en lugar de ignoración.

7.4 Función de operación del conjunto de señales

El tipo sigset_t utiliza un bit para representar el estado "válido" o "no válido" de cada señal. En cuanto a cómo almacenar estos bits dentro de este tipo, depende de la implementación del sistema. Desde la perspectiva del usuario, no es necesario en cuestión. El usuario debe llamar a la siguiente función . Operar la variable sigset_t sin ninguna explicación de sus datos internos. Por ejemplo, no tiene sentido imprimir directamente la variable sigset_t con printf.

#include <signal.h>
int sigemptyset(sigset_t *set);//置空
int sigfillset(sigset_t *set);//置满
int sigaddset (sigset_t *set, int signo);//添加信号到信号集
int sigdelset(sigset_t *set, int signo);//在信号集中删除指定信号
int sigismember（const sigset_t *set, int signo); //在信号集查找是否有该信号

Estas cuatro funciones devuelven 0 en caso de éxito y -1 en caso de error. sigismember es una función booleana que se utiliza para determinar si una determinada señal está incluida en las señales válidas de un conjunto de señales. Si está incluida, devuelve 1, si no está incluida, devuelve 0 y si falla, devuelve - 1.

 

7.5 Llamar a la función sigprocmask puede leer o cambiar la palabra de máscara de señal (conjunto de señales de bloqueo) del proceso.

7.6 pendiente

#include <signal.h>
sigpending
读取当前进程的未决信号集,通过set参数传出。调用成功则返回0,出错则返回-1。 

 7.7 Impresión de señales pendientes cuando las señales están bloqueadas 

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

using namespace std;
void my_printf_sig(sigset_t* a){
    for(int i=0;i<65;i++){
        if(sigismember(a,i)){
            cout<<"1";
            //cout<<"         "<<i<<"**********";

        }
        else{
            cout<<"0";
        }
    }
}

int main(){
    sigset_t block,pending;
    sigemptyset(&block);
    for(int i=0;i<65;i++){//将所有的信号都屏蔽了，但是kill -9 还是可以生效。
        sigaddset(&block,i);
    }
    sigprocmask(SIG_BLOCK,&block,NULL);

    while(1){
        sigpending(&pending);
        my_printf_sig(&pending);
        cout<<endl;
        sleep(1);
        cout<<"my_pid is"<<getpid()<<endl;

    }
}

7.8 Cómo el kernel implementa la captura de señales 

Si la acción de procesamiento de la señal es una función definida por el usuario, esta función se llama cuando se entrega la señal, lo que se denomina captar la señal. Dado que el código de la función de procesamiento de señales está en el espacio del usuario, el proceso de procesamiento es relativamente complicado. Por ejemplo, el programa de usuario registra el singhandler de la función de procesamiento de señales SIGQUIT. La función principal se está ejecutando actualmente. Cuando ocurre una interrupción o excepción, el sistema cambia al estado del kernel. Después de procesar la interrupción, se verifica que se entregue la señal SIGQUIT antes de regresar a la función principal en modo usuario. El kernel decide no restaurar el contexto de la función principal y continuar la ejecución después de regresar al modo de usuario, sino ejecutar la función sighandler. Las funciones sighandler y main usan diferentes espacios de pila. No hay relación entre llamar y ser llamado. Son Dos procesos de control independientes. Una vez que regresa la función sighhandler, ejecuta automáticamente la llamada especial al sistema sigreturn y ingresa nuevamente al estado del kernel. Si no hay nuevas señales para entregar, regresar al modo de usuario esta vez restaurará el contexto de la función principal y continuará la ejecución.

7.9 sigaction

7.9.1 Definición de siacción 

• sa_handler es un puntero de función que especifica la función de procesamiento de señal. Además de nuestra función de procesamiento personalizada, también puede ser SIG_DFL (usando el método de procesamiento predeterminado) o SIG_IGN (ignorando la señal). Su función de controlador tiene un solo parámetro, el valor de la señal.
•    sa_mask es un conjunto de señales que puede especificar qué señales deben enmascararse durante la ejecución del controlador de señales. Antes de llamar a la función de captura de señales, el conjunto de señales debe agregarse a la palabra de máscara de señal de la señal.
•    sa_flags contiene muchos bits de bandera, que son varias opciones para el procesamiento de señales. Sus valores opcionales comunes se muestran en la siguiente tabla.

8. volátil:

La función de volátil: mantiene la visibilidad de la memoria y le dice al compilador que las variables modificadas por esta palabra clave no pueden optimizarse y cualquier operación sobre esta variable debe realizarse en la memoria real. 

9. Señal SIGCHLD

El proceso principal llama a sigaction para establecer la acción de procesamiento SIGCHLD en SIG_IGN, de modo que el proceso secundario bifurcado se limpie automáticamente cuando finalice, no se generará ningún proceso zombie y no se notificará al proceso principal. Por lo general, no hay diferencia entre la acción de ignorar predeterminada del sistema y la acción de ignorar definida por el usuario usando la función sigaction, pero este es un caso especial. Este método está disponible para Linux, pero no se garantiza que esté disponible en otros sistemas UNIX.

#include <iostream>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <signal.h>
#include <sys/types.h>
#include <sys/wait.h>

using namespace std;

void sigchld_handler(int signum)
{
    // 处理SIGCHLD信号，可以不需要具体的逻辑
    // 在这个示例中，我们可以仅仅打印一条消息
    printf("Received SIGCHLD signal\n");
}

int main()
{
    // 设置SIGCHLD的处理动作为SIG_IGN
    // struct sigaction sa;
    // sa.sa_handler = SIG_IGN;
    // sigemptyset(&sa.sa_mask);
    // sa.sa_flags = 0;
    // sigaction(SIGCHLD, &sa, NULL);

    pid_t pid = fork();

    if (pid == 0)
    {
        // 子进程
       // printf("Child process\n");
        cout << "child process pid is : " << getpid() << endl;

        // do something...
        sleep(30);
        cout << "child exit" << endl;
        exit(0);
    }
    else if (pid > 0)
    {
        // 父进程
       // printf("Parent process\n");
        cout << "parent process pid is : " << getpid() << endl;

        // 等待子进程结束
        sleep(100); // 等待足够长的时间，以确保子进程已经结束
        printf("Parent process exiting\n");
    }
    else
    {
        // fork失败
        printf("Fork failed\n");
        return 1;
    }

    return 0;
}

// while :; do ps axj|head -1&& ps axj |grep sig_ignore|grep -v grep;sleep 1; done;

Resumen de pensamiento:

所有信号产生，最终都要有OS来进行执行，为什么？OS是进程的管理者 




信号的处理是否是立即处理的？在合适的时候 




信号如果不是被立即处理，那么信号是否需要暂时被进程记录下来？记录在哪里最合适呢？ 
在Linux中，如果信号在接收时不能立即处理，进程通常需要将信号记录下来以便稍后处理。Linux使用信号队列来存储接收到但尚未处理的信号。
每个Linux进程都有一个信号处理器表，用于存储信号处理程序的地址。当进程收到一个信号时，操作系统会根据进程的信号处理器表确定应该执行哪个信号处理程序。
在信号处理期间，Linux使用信号屏蔽字和挂起信号队列来处理挂起的信号。挂起信号队列是内核中的数据结构，用于存储挂起的信号。当进程正在处理信号时，其他同类信号可能会被挂起，并在当前信号处理程序完成后按照一定的优先级顺序逐个处理。
挂起信号队列位于内核中，因此信号被记录在内核的上下文中。这种设计可以保证在进程切换时仍然可以正确处理挂起信号。
最合适记录信号的位置是在Linux内核的信号挂起队列中。这样，在进程重新调度执行时，操作系统可以检查信号挂起队列并将挂起的信号传递给进程进行处理。
需要注意的是，Linux对于不同类型的信号有不同的处理机制。一些信号（如SIGSTOP和SIGKILL）不能被挂起，它们会立即中断进程的执行。但大多数其他信号可以挂起并在适当的时候处理。
总之，Linux使用信号挂起队列来记录未立即处理的信号。这种机制确保了信号的顺序和正确处理，同时保证了信号的可靠交付。





一个进程在没有收到信号的时候，能否能知道，自己应该对合法信号作何处理呢？
能够，信号的默认处理动作在linux的内核中 








如何理解OS向进程发送信号？
理解操作系统（OS）向进程发送信号可以从两个方面来考虑：

1.异步事件通知：操作系统可以在特定事件发生时向进程发送信号，以通知进程发生了某些异步事件。这些事件可能包括：


用户按下特定的键盘组合，例如Ctrl+C，触发SIGINT信号。
定时器到期，触发SIGALRM信号。
子进程终止，触发SIGCHLD信号。
硬件故障，例如除零错误，触发SIGFPE信号。
当这些事件发生时，操作系统会向目标进程发送相应的信号，以便进程可以作出相应的反应。这可以通过操作系统的信号传递机制实现，如Linux中的信号队列。


2.进程间通信：除了异步事件通知外，操作系统还可以通过信号在进程之间进行通信。进程可以向其他进程发送信号以触发特定的行为或进行协调。这可以用于以下情况：


进程间的同步和通知：一个进程可以向另一个进程发送信号来通知某个事件的发生，以便目标进程进行相应的处理。例如，父进程向子进程发送信号以指示某个任务已完成。
进程控制和管理：某些信号可以用于控制和管理进程。例如，通过SIGKILL信号可以强制终止一个进程，通过SIGSTOP信号可以暂停一个进程的执行。
信号处理程序的使用：进程可以注册自定义的信号处理程序，当接收到特定信号时，操作系统会调用该处理程序来执行特定的操作。这样进程就可以利用信号处理程序来处理特定事件或执行自定义逻辑。

总体而言，操作系统通过向进程发送信号，实现了事件通知、进程间通信和进程控制等功能。这为进程提供了一种有效的方式来与操作系统进行交互，并实现合适的响应和协作。




能否描述一下完整的发送处理过程？
当进程发送信号时，它调用kill()、raise()或发送信号的相关系统调用。内核接收到信号后，会检查接收进程的权限和状态。如果接收进程具有对该信号的处理程序，并且信号未被阻塞，则内核会将信号递交给接收进程的信号处理程序。如果接收进程没有对信号进行处理或信号被阻塞，则内核采取默认的行为，如终止进程(SIGKILL)或忽略该信号(SIGIGN)。整个过程涉及信号发送、接收进程状态检查以及信号的处理或默认行为的执行。
详细版：
发送信号：

信号源：信号可以来自多个源头，例如操作系统触发的异步事件、其他进程的信号发送、硬件中断等。
信号发送：信号源通过系统调用（如kill()）或其他适当的机制向目标进程发送信号。发送信号时，需要指定目标进程的标识符，如进程ID（PID）或进程组ID（PGID）。
接收信号：

目标进程：操作系统在目标进程上选择一个合适的执行点来接收信号。这通常是在进程的用户态代码执行时进行检查。
信号递交检查：目标进程在执行期间会定期进行对信号的检查，以确定是否有新的信号需要处理。这个过程通常是由操作系统提供的信号传递机制完成的。
信号处理：

默认行为：如果进程未注册特定信号的处理程序，或者没有明确指定默认操作的信号，操作系统将使用默认的信号处理行为来处理信号。这可能包括终止进程、忽略信号或者进行其他特定的操作。
自定义处理程序：进程可以使用系统调用（如signal()或sigaction()）注册自定义的信号处理程序。当信号到达时，操作系统会调用相应的信号处理程序来执行特定的操作或指令。
信号处理程序执行：

信号处理程序执行在进程的上下文中，可以执行特定的代码逻辑来响应信号。信号处理程序可以进行一系列操作，如记录日志、修改进程状态、发送其他信号等。
注意，由于信号处理程序在进程的执行上下文中执行，它必须是轻量级且可靠的。一些操作（如堆内存分配和长时间的计算）可能不适合在信号处理程序中执行。
信号处理完成：

处理结果：信号处理程序完成后，进程可以根据需要执行后续操作，并继续执行原始代码逻辑。
信号状态更新：处理完信号后，操作系统将清除信号的挂起状态，并允许其他信号继续递交给进程。
这是一个基本的信号发送和处理过程的概述。具体的实现细节和行为取决于操作系统和编程语言的规范。不同的操作系统和编程语言可能有自己的信号处理机制和可调整的参数。因此，在具体的应用环境中，还需要参考相关的文档和规范来了解操作系统的具体行为和限制





挂起的信号是指在信号处理程序执行期间接收到的但还没有被处理的信号。当一个进程正在执行信号处理程序时，如果这个进程收到了其他信号（除了一些特定的硬件相关信号），这些新的信号将会被挂起，即暂时不会被递交给进程。相反，这些挂起的信号会等待当前正在执行的信号处理程序完成后再进行递交。这种机制保证了信号处理程序的一致性和可靠性。