[lkml]   [2005]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-05-11 21:03    [W:0.050 / U:0.624 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site