In Linux / C ++, does a thread / process send a thread to become active?
On Linux, when a signal is sent to a process / thread (for whatever reason), is the signal handler (if there is one and the signal is not blocked) gets called immediately?
I mean, I'm pretty sure the process / thread that is handling the signal will call it immediately, but I mean with respect to other processes / threads.
And if the handler is called immediately, will it also activate the corresponding process / thread (so that its normal execution continues immediately)?
EDIT
As my original question seems to have been misunderstood, I'll try to explain again with an example.
Suppose on my computer I have one processor and two processes processing "A" and "B". And suppose none of them block the system call (e.g.sleep
). Usually, I think the OS will switch between executing process "A" and process "B" at short intervals (for example, do process "A" for 100ms, then process "B" for 100ms, and then process A again in 100 ms, etc.). Let's say that process "A" is now an active process (ie the one that is currently occupied by the processor). Tell now that process "A" sends a signal to process "B" (or alternatively, the OS sends this signal to process "B" for whatever reason). Process B has registered a handler for this signal and is not blocking it. So the question is, will the OS immediately stop executing process "A" and switch to executing the signal handler of process "B"? And if the answer is yes,will it immediately continue the execution of process "B" (normal code, not a signal handler), or will it return to the execution of process "A" and only after a short period of time resume the execution of process "B"?
And then you can ask the same questions about threads and not about processes.
source to share
No, signals are transmitted only in the context switch. Until that time, all signals will be queued. Among many signals of the same type, usually only one signal is delivered to its destination. Therefore, I am comfortable sitting, that more signals are destroyed than delivered. I suggest you refer to the chapter on any Unix book. My favorite is understanding linux kernel and Linux kernel development. if you still need technical help please comment on this.
source to share
There are two cases: when the signaling process is active and when it is blocked.
In the first case, according to http://www.tldp.org/LDP/tlk/ipc/ipc.html , the process will handle the signal when it exits the system call. This would mean that a normal instruction like a = b + c (or its equivalent machine code) would not be interrupted by a signal. Signal processing can also be delayed in a processor intensive process.
However, when a process blocks, it depends on whether a kernel function is interrupted (for example, wait_event_interruptible). If it interrupts, the process will wake up, otherwise it won't wake up until it leaves the function uninterrupted (due to IRQ for example).
source to share
And if the handler is called immediately, will it also make the corresponding process/thread active (so that its normal execution continues immediatly)
Your signal handler has its own context. Thus, there is no thread that needs to be activated to handle your signal. But there are some questions to keep in mind. If your thread is waiting for some system calls, such as sleep
or read/write
any other blocking operation, this system call will be interrupted and the return value of this call will give you information that your process (not the thread!) Received a signal. This is the return value EINTR
. If your thread is just running or sleeping without waiting for a system call, nothing else happens! It's just that the handler is called without any changes to the scheduling of your threads within your process.
source to share
Yes, the handler will be called immediately. Suppose I have a process coded like below.
#include <stdio.h>
#include <signal.h>
void handle_signal(int signal);
volatile int i = 1;
int main( )
{
struct sigaction sa;
// Setup the sighub handler
sa.sa_handler = &handle_signal;
// Block every signal during the handler
sigfillset(&sa.sa_mask);
while(1)
{
if(i == 1)
{
printf("A");
}
}
return 0;
}
void handle_signal(int signal) {
/*
* Please note that printf et al. are NOT safe to use in signal handlers.
* Look for async safe functions.
*/
const char *signal_name;
sigset_t pending;
// Find out which signal we're handling
switch (signal) {
case SIGHUP:
signal_name = "SIGHUP";
break;
case SIGSTOP:
i = 0;
signal_name = "SIGSTOP";
break;
case SIGCONT:
signal_name = "SIGCONT";
i = 1;
break;
default:
fprintf(stderr, "Caught wrong signal: %d\n", signal);
return;
}
}
This prints A
to the shell all the time until it receives a signal SIGSTOP
. So, open a shell and do kill -STOP <pid of above process>
Make sure the process is stopped and then from the shell send a signal SIGCONT
usingkill -CONT <pid of above process>
source to share