Messages in this thread | | | Date | Wed, 11 May 2005 20:58:29 +0200 | From | Olivier Croquette <> | Subject | Re: Scheduler: SIGSTOP on multi threaded processes |
| |
Hello Roland
Thanks for your reply.
>>- Can a SIGSTOP be in a pending state in Linux? > > For short periods. > >>- If kill(SIGSTOP,...) returns, does that mean that the corresponding >>process is completly suspended? > > No. One or more threads of the process may still be running on another CPU > momentarily before they process the interrupt and stop for the signal.
I get sometimes 150ms delay between the end of kill() and suspension of the last thread of the 3 threads, on a single-CPU system (Pentium 4).
It seems understandable to me to have a delay of <=1ms, especialy on SMP systems, but I really can't understand:
- the so big delays (like the 150ms)
- why only multi-threaded applications make problems
- why the policy of the programs has an impact on the results
- why for some executions, the SIGSTOP effect is instantaneous 100s of times in a row, until the end of the test, and the next execution shows delays right from the beginning
I don't have much experience hacking the kernel, are these behaviours are quite difficult for me to monitor or trace. I am beginning to run out of ideas to test further :(
Could it be that my observations undercover a problem? Or are the a consequence of the Linux implementation? Or do I have a problem in my test bench?
Can anyone reproduce and/or validate these observations?
Any hint would be appreciated! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |