On Tue, Sep 29, 2009 at 09:15:08PM +0800, ???? ?? wrote:
> 
> Thank you for your reply!
> 
> My words is a little confused:)
> 
> to simplify it, we assume fork1() is invoked by PT. In your words,"The
> kernel thread stack is not copied or shared between PT and CT" , but
> forklwp() invokes lwp_forkregs(lwp, clwp) which to copy struct regs in
> kernel stack frame from PT to CT.

Right.  So the new thread starts with the same register set as the parent,
except that:

usr/src/uts/common/os/fork.c:
 509         if (PROC_IS_BRANDED(p))
 510                 BROP(p)->b_lwp_setrval(clone, p->p_pid, 1);
 511         else
 512                 lwp_setrval(clone, p->p_pid, 1);
 513 
 514         /* set return values for parent */
 515         r.r_val1 = (int)cp->p_pid;
 516         r.r_val2 = 0;

The parent gets (child pid, 0), and the child gets (parent pid, 1) in the
syscall return value registers.

> It means that CT will be dispatched to execute lwp_rtt_initial() in
> kernel mode,which invoke IRET instruction to translate from kernel
> mode to userland.

Indeed.
> because CT's kernel stack frame is copied from PT, it will execute the
> code after fork() in PT.

I'd say that CT's user-space register set was copied from PT.  Calling it
a kernel stack frame is a bit misleading.

> *USER CODE AS FOLLOWS:*
> 
> ////////////////////////////////
> 
> int ret = fork();
> 
> if (ret > 0) {
> 
> // in parent process
> 
> } else if (ret == 0) {
> 
> // in child process
> 
> }
> 
> ////////////////////////////////
> 
>  
> 
> Yesterday I think that CT has no user thread struct named ulwpt_t, how
> it is to control userland exuction flow?
>
> Now It seems that the as struct is copied from PP to CP.PP and CP
> share the same process address space this time.When CT to execute the
> text code,because of copy on write(COW),the page frames involving
> ulwp_t struct will copied for CP.Now CT has its own ulwp_t struct, it
> conforms to that a process's thread has an ulwp_t struct, a klwp_t
> struct and a kthread_t struct.

> Oh,Is That right?

Yup;  all user-space state is COWed from the state of the parent, so the
new thread's ulwp_t is at the same virtual address as the parents, and
starts out as a copy of PT's ulwp_t.

Once CT gains control and returns to userland, libc (which has the thread
interfaces in Solaris) does have to clean up a bit, especially after a
non-forkall() fork.  If you're curious, take a look at forkx() and forkallx()
in usr/src/lib/libc/port/threads/scalls.c.

Cheers,
- jonathan

>
>  
> 
> 
>  
> > Date: Mon, 28 Sep 2009 09:24:35 -0700
> > From: jonathan.adams at sun.com
> > To: mydino_vi at hotmail.com
> > CC: on-discuss at opensolaris.org
> > Subject: Re: [on-discuss] question about cfort
> > 
> > On Mon, Sep 28, 2009 at 09:09:42PM +0800, ?? ? wrote:
> > > 
> > > For example, 
> > > 
> > > the some thread maked by PT in parent process marked by PP
> > > invoked syscall fork(), cfork() is invoked in the kernel
> > > state which create child process marked by CP, CP's proc
> > > struct(as,p_exec,p_user,klwp_t/kthread pairs) is duplicated by PP's
> > > proc.
> > 
> > To re-write:
> > 
> > Some thread (PT) in a process (PP) invoked the "fork" syscall, which
> > causes the kernel function cfork() to be called. This creates a child
> > process (CP), whose state is a duplicate of PP's.
> > 
> > > Besides the kernel stack of CP's kthread is equal to the kernel
> > > statck of PT,so CP's current thread is dispatched by cpu to execute
> > > the code after fork() in PT thread code.
> > > 
> > > Question:CP has no any user thread(ulwp_t), why not duplicate ulwp_t? 
> > > 
> > > Is PT's ulwp_t shared by PP and CP? if so, it is not conform 
> > > ulwp_t:klwp_t:kthread_t=1:1:1?!
> > 
> > I'm not sure exactly what you're asking here. Assuming we're talking
> > about fork1() (which only creates one thread in CP), cfork() will
> > create a single thread (CT) in the child, using the "forklwp()"
> > call, which creates threads and associated LWPs, and duplicates the
> > *userland* thread state from PT. The kernel thread stack is not copied
> > or shared between PT and CT; the CT starts out with an empty stack in
> > lwp_rtt_initial(), an assembly routine which sets up the stack, does some
> > initial dtrace probes, and returns to userland.
> > 
> > Does that answer your question?
> > 
> > Cheers,
> > - jonathan
> > 
>                                         
> _________________________________________________________________
> Invite your mail contacts to join your friends list with Windows Live Spaces. 
> It's easy!
> http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us

Reply via email to