LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Kernel (https://www.linuxquestions.org/questions/linux-kernel-70/)
-   -   Problem with Signals in multiprocessor multi threaded applications (https://www.linuxquestions.org/questions/linux-kernel-70/problem-with-signals-in-multiprocessor-multi-threaded-applications-724414/)

digvijay.gahlot 05-07-2009 09:42 AM

Problem with Signals in multiprocessor multi threaded applications
 
Hi.

When does an process response to a signal like SIGQUIT? I mean to say if the process is executing in the kernel space it will only respond to the signal once it comes back to user space. If it never returns from kenel space the signal cannt be processed.

If I am wrong plz correct me.

We have a scenario we have a multiprocessor system and multithreaded process running on all processors.

One of the thread in the process is in kernel mode. What will happen if a SIGQUIT is send from the second process running at the other processor.

In case another thread in the 1st process get a chance to run (which is at user space )receives the signal how will t response?

Thanks in advance

titan22 05-07-2009 01:37 PM

Your first sentence "if it never returns from kenel space the signal cannt be processed." is correct.

Threads (in proceses 1) in user space will process the SIGQUIT handler immediately and exit. The reason they will process immediately is because for example timer interrupt happens so frequently that drives the running user threads in and out user/kernel space all the time.

The pending signal is still attached to the process(thread group to be more accurate) as long as there are still threads in this group. The thread in kernel space will eventually return to user space and process the SIGQUIT handler. The pending SIGQUIT signal is cleared when all threads in the thread group have processed the SIGQUIT handler.

digvijay.gahlot 05-08-2009 12:51 AM

Thanks Titan,

You said when all threads have processed the signal. We have a case here where one thread is not coming back from kernel space. So I do believe that the Process will have to wait for the return.

Moreover if that thread in kernel space has been placed in a wait_queue wil there be any other scenario?

Thanks again

titan22 05-08-2009 02:16 PM

If the target thread is expecting an signal it should go to sleep by setting TASK_INTERRUPTIBLE state. Threads in TASK_UNINTERRUPTIBLE won't be woken up by signals.

The target thread in TASK_INTERRUPTIBLE state (wait_queue kernel mode) will be woken up when a SIGQUIT signal is sent by other threads. The woken thread should check if there is a pending signal and decides if it should go back to sleep (wait_queue) or bail out with EINTR. Eventually the thread is back to user mode and the signal handler will be processed.

Hundreds of examples are available if you search "TASK_UNINTERRUPTIBLE".

set_current_state(TASK_INTERRUPTIBLE);
add_wait_queue(&conn->chanwait, &myself);

..... check signals when woken up ....

ret = -EINTR;
if (signal_pending(current))
goto error_unwait;

digvijay.gahlot 05-11-2009 12:29 AM

Thanks Titan22

I found out that any active thread in the 1st application can receive the SIGQUIT and will take action for the whole process. So whether other threads are in kerner/user space won't make a difference unless we want the signal to be handled by specific thread.

Thanks again


All times are GMT -5. The time now is 03:32 AM.