Yes. Do a quick grep for functions calling do_fork in arch/x86/kernel/* -Joel On Sat, Jan 16, 2010 at 10:40 PM, Daniel (Youngwhan) Song <breadncup@xxxxxxxxx> wrote: > Thank you, Mulyadi, now, I could understand about NPTL implementation and > lightweight process concept. > > One thing I want to check is that it looks that the system call, clone() > eventually calls do_fork() in fork.c > (http://lxr.linux.no/#linux+v2.6.32/kernel/fork.c#L1375) which is the last > stage of the creation of thread. > > So, it looks like fork(), vfork(), and clone() system calls through > sys_fork(), sys_vfork(), sys_clone(), and they are eventually calls > do_fork(). > > Best Regards, > Daniel (Youngwhan) Song > > > > On Sat, Jan 16, 2010 at 8:22 AM, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> > wrote: >> >> Hi Daniel.... >> >> On Sat, Jan 16, 2010 at 6:28 PM, Daniel (Youngwhan) Song >> <breadncup@xxxxxxxxx> wrote: >> > To confirm again, >> > >> > Since kernel thread by kernel_thread() is created by do_fork() in the >> > kernel, pthread_create() uses clone() system call which eventually calls >> > do_fork() in the kernel, and fork() in user space calls eventually >> > do_fork() >> > as well, all threads/process are manged by task_struct with different >> > configuration(flags). Is this correct? >> >> I think it's the other way around...do_fork() eventuall calls clone() >> with various flags, depending on the intention of the caller. >> >> > If then, is my understanding that the implementation of do_fork() is by >> > NPTL >> > in linux 2.6 correct? >> >> NPTL is a complete implementation of threading both in user space >> (mostly in glibc AFAIK) and kernel space (by system calls and related >> kernel infrastructure), including signal handling etc etc. do_fork() >> is just a part of it >> >> > If so, there is no heavy process in the linux in typical. Right? >> >> If you're using the logic that forking is relatively "cheap" due to >> using COW, then yes it's quite cheap. >> >> However, I believe the label LWP is strictly connected to thread due >> to one property: threads are sharing process address space, thus >> during context switch between threads in the same thread group, it >> could be done fast because there is no need to flush TLB and switch to >> another PGD. >> >> -- >> regards, >> >> Mulyadi Santosa >> Freelance Linux trainer and consultant >> >> blog: the-hydra.blogspot.com >> training: mulyaditraining.blogspot.com > > -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
