Thank you for clarification!
> Date: Tue, 29 Sep 2009 08:24:09 -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 cfork
>
> 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
_________________________________________________________________
Windows Live?: Keep your life in sync. Check it out!
http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/on-discuss/attachments/20090930/762cf648/attachment.html>
