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!
-
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/