On Mon, Oct 6, 2008 at 12:03 PM, Mitul Modi <[EMAIL PROTECTED]> wrote: > hi Lal, > > thanks for the analysis and clearing the doubt. so, parent process returns > while child is added in to runqueue. right? >
Depends. For example if CLONE_VM is not set, then kernel runs child process first in anticipation of an exec to avoid COW overhead. If CLONE_VM is set then kernel puts the child process at the end of runqueue. The parent process continues through ret_from_intr where kernel may again decide to schedule it out and run another process (may be child process or some other). Regarding CLONE_PARENT_SETTID discussion above, I would like to add that child process pid is returned to a parent process user space pointer only if CLONE_PARENT_SETTID is set; otherwise parent process also returns child process pid through %eax. This mechanism is required to cater different application requirements through a single do_fork function. For example, pthread_create returns thread handle (which internally may have many other variables including child pid) through an argument, therefore pthread_create calls clone system call with CLONE_PARENT_SETTID set, while fork() returns child pid through fork return value, therefore clone system call is called without CLONE_PARENT_SETTID. -Lal -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to [EMAIL PROTECTED] Please read the FAQ at http://kernelnewbies.org/FAQ
