Re: Scheduler: SIGSTOP on multi threaded processes

[Olivier Croquette <ocroquette@free.fr>]

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!