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