Re: Scheduler: SIGSTOP on multi threaded processes

[Alexander Nyberg <alexn@dsv.su.se>]

> On a 2.6.11 x86 system, I am SIGSTOP'ing processes which have started 
> several threads before.
> 
> As expected, all threads are suspended.
> 
> But surprisingly, it can happen that some threads are still scheduled 
> after the SIGSTOP has been issued.
> 
> Typically, they get scheduled 2 times within the next 5ms, before being 
> really stopped.
> 
> Sadly, I could not reproduce that in a smaller example yet.
> 
> As this behaviour is IMA against the SIGSTOP concept, I tried to analyze 
> the kernel code responsible for that. I could not really find the exact 
> lines.
> 
> So here are my questions:
> 
> 1. do you know any reason for which the SIGSTOP would not stop 
> immediatly all threads of a process?

The following scenario is possible:
program1 with a thread thread1

1) you send SIGSTOP to program1
2) thread1 is now scheduled and run.
3) program1 is now run and before it is scheduled off it notices it has
a signal set, makes sure all threads in the group gets SIGSTOP set.
4) thread1 is now scheduled and run again. now before it is scheduled
off it will find a signal pending and set itself in SIGSTOP.

There are absolutely no guarantees when a signal will be delivered.
Signals are delivered asynchronously.

> 2. where do the threads get suspended exactly in the kernel? I think it 
> is in signal.c but I am not sure exactly were.

do_notify_resume()
	do_signal()
		get_signal_to_deliver()
			do_signal_stop()
				finish_stop()

> 3. can you confirm that the bug MUST be in my code? :)

You'll have to use reliable mechanisms to achieve what you're looking
for.