Re: [uml-devel] Question about the kernel thread in UML TT mode

[Jeff Dike <jdike@addtoit.com>]

On Wed, May 18, 2005 at 06:04:31PM +0800, Alex LIU wrote:
> But P and Q are different threads and they will be scheduled
> differently,right?

No, they're two different ways of looking at the same thread.  They're 
scheduled somewhat differently, but that's just reflecting the two ways
of looking at it.  If it's runnable on the host, it's runnable inside UML,
but not the other way around.

> Another question:
> when a kernel thread is created in UML, in the function outer_tramp the temp
> thread A will clone the corresponding host thread B and then wait for it to
> stop. The code is following:
> 
> 	t->pid = clone(t->tramp, (void *) t->temp_stack + page_size()/2,
> 		       t->flags, t->tramp_data);
> 	if(t->pid > 0) wait_for_stop(t->pid, SIGSTOP, PTRACE_CONT, NULL);
> 
> And once the host thread B is created it will run new_thread_proc,in the
> function the thread send the signal SIGUSR1 to itself:
> 
> 	os_usr1_process(os_getpid());
> 	change_sig(SIGUSR1, 1);
> 	return(0);
> 
> But I found the thread B will be blocked in the function change_sig(SIGUSR1,
> 1). Why?

It's not blocked there.  That makes it enter the SIGUSR1 handler, which puts
it on its kernel stack.

> And in the function outer_tramp, the thread A see the thread B was stopped
> with a SIGSTOP signal. Why? Since the thread B is blocked by the signal
> SIGUSR1...

The handler calls suspend_new_thread, which stops itself.

				Jeff


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel