On Sun, Jun 6, 2010 at 3:06 AM, Vimal <j.vimal@xxxxxxxxx> wrote: > Hi Joel, > >> >> now i have a question, even if they share the same vm address space - >> they definitely can't share the userspace stack, i'm sure the kernel >> would have to reset it up in the same address space of the group of >> threads but I really don't know how that works - could you share your >> thoughts on this? > > I get what you're telling. I don't know how it's implemented, but it > would be easier to think of it this way: A thread control block has > pointers to the process control block (which contains the list of fds, > sighands, the page tables, etc.), and the thread context (the set of > general purpose registers). So two threads of the same process will > have the same PCB but different TCB. So when a context switch occurs > between threads of different PCBs, it's a context switch to a > different process. I know we're digressing slightly from the original topic a bit a bit I'm just curious to know how/where the new user-mode stack is setup for a thread that shares the address space of the cloning thread. It appears that a new user mode stack is setup in the load_binary function which is called during exec() . But I don't see where the new stack for the thread is created during a clone() with CLONE_VM flag set. During clone, the address spaces are shared , task_struct and thread_info are copied, a new kernel mode stack is created, but I don't see where a new userspace stack for the new thread is created. neither is the stack pointer value changed in the new task_struct (process control block), it is simply a copy of the process that cloned/forked. I wonder if this is setup in userspace itself by a thread library? thanks, Joel -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
