Application of signal shielding characters in multi-threaded Environments

1. signal shielding and sigprocmask Functions

Each process hasSignal mask)It specifies the signal set to block delivery to the process. Each possible signal corresponds to one of the shielded characters.

Processes can callSigprocmaskFunction.

2. Signal Generation, delivery, and pending status

1) First, when a signaling event occursGeneration)One signal (or send a signal to the process ).

Note: events can be hardware exceptions (for example, dividing by 0), software conditions (for example, alarm timer timeout), signals generated by terminals, or kill functions.

2) When a signal is generated, the kernel usually sets a certain form of sign in the progress table. When we take this action on the signal, we say to the ProcessDelivery (delivery)A signal.

3) The signal is calledPending).

3.Pending status of blocked Signal

As stated in 1, you can call the sigprocmask function to block the signal.

If a blocking signal is generated for the process, andThe default action on the signal or capture the signalThe Process maintains the signalPending status. Until the process (a) unblocks the signal (also by calling the sigprocmask function), or (B)Change the action on this signal to ignore.

Processes can callSigpendingFunction to determine which signals are set to blocking and in the pending status.

Note: If a signal occurs multiple times during blocking. In most Unix systems, the signal is not delivered multiple times, but only once.

Summarize the above knowledge:When a blocked signal is set, if the process's action on the signal is default (sig_def) or captured (by setting a custom processing function, the kernel keeps the signal in the pending state and waits for the blocking to be canceled before delivery. If the process ignores the signal, the kernel does not keep the signal and directly ignores it.

The following describes the application of this mechanism in a multi-threaded environment:

First, you need to know: In a multi-threaded environment,Each thread has its own signal shielding word,Processing of signals shared by all threads in a process.

That is, if you modify the processing method of a signal in a thread, it is equivalent to modifying the processing method of the signal by all threads in the process.

1. Thread shielding of Signals

The sigprocmask function can only be used in a single-threaded environment. In a multi-threaded environment, the corresponding function is --Pthread_ Sigmask. This function is basically the same as the sigprocmask function.

2.SigwaitFunction

The thread can call the sigwait FunctionWait for one or more signals to occur. The first parameter of this function specifies the waiting signal set. The second parameter is used as the return value, indicating the signal actually received.

If a signal in the signal set specified by the first parameter is in the pending status when sigwait is called, sigwait will return immediately).

Combined with the pthread_mask and sigwait functions, the signal processing in a multi-threaded environment can be simplified:

To prevent the thread from being interrupted by a signal, you can

(1) set the Signal Processing Method to the system default.

(2) Add it to the signal shielding characters of each thread (call the pthread_mask function)

(3) Arrange a dedicated thread to call the sigwait function in the thread to wait for the signal, and process the signal in the thread (if waiting)

If a signal is generated in the process, the signal is in the pending state because it is blocked in all threads and the signal is processed in the default way. When sigwait called by the dedicated thread detects the signal, it immediately returns, indicating that the signal is waiting for processing.

This method can be used to capture the sig_hup signal by the daemon.

There is a problem in the multi-threaded environment:If a signal is sent to a process, which threads in the process will receive the signal?

For this question, the book "Advanced Programming for UNIX environments" says this:Signals in a process are delivered to a single thread. If the signal is related to a hardware fault or timer timeout, the signal is sent to the thread that caused the event, and other signals are sent to any thread.

To understand the last sentence, we made a simple test:

1) fork a sub-process in the main function

2) set the processing method of SIGUSR1 to capture in the sub-process and customize the processing function sig_usr1. The operation of the processing function is to print the thread ID and process ID of the thread that captures the signal.

3) create a new thread in the sub-process. The new thread shares sig_usr1 with the main thread.

4) The main thread and new thread of the sub-process call the pause function to wait for the signal.

5) in the parent process, first sleep for 3 seconds (set the signal processing function for the child process and the time for creating the thread), and then send SIGUSR1 to the child process

The running result is:This signal is always received by the main thread, but not by the new thread.. (I don't know why the number of tests is small ...)

Make some modifications to the above program:

1) shield SIGUSR1 in the main thread of the sub-process, and then sleep for 10 seconds instead of calling the pause wait signal.

A) if the new thread is not modified and the pause wait signal is still called, the main thread and the new thread will not capture the signal. The sub-process will exit normally as it goes to sleep.

B) if the new thread does not call pauseCall the sigwait function to wait for SIGUSR1, and the new thread will wait for the function. However, the specified signal processing function sig_usr1 is not called., But continues to execute. Therefore, when calling the sigwait function to wait for a signal, you need to re-compile the corresponding operations on the signal after waiting.