fork: why to copy process to run new program?

fork: why to copy process to run new program?

[Tom]

        Hello!

        Why, when a program needs to open another, have fork to copy all the
initial program just for 'exec' the another? Could'nt initial program just
to "tell" the kernel for open the second program?



        Thank you
        Tom

Re: fork: why to copy process to run new program?

[Ron Michael Khu]

u can :D
if u dont need the original program's functionality... then call exec 
right away :D

calling exec will replace the calling process's program space... so it's 
really up to you

Tom wrote:

>        Hello!
>
>        Why, when a program needs to open another, have fork to copy all the
>initial program just for 'exec' the another? Could'nt initial program just
>to "tell" the kernel for open the second program?
>
>
>
>        Thank you
>        Tom
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>  
>

Re: fork: why to copy process to run new program?

[Glynn Clements]

Tom wrote:

>         Why, when a program needs to open another, have fork to copy all the
> initial program just for 'exec' the another? Could'nt initial program just
> to "tell" the kernel for open the second program?

I'm not sure what you're getting at.

If you're asking why fork() and exec() can't be combined into a single
spawn() primitive, the answer is twofold:

1. A spawn() primitive would only handle the simplest cases. It's
quite common for there to be non-trivial code in the child branch
before the exec(), e.g. redirecting descriptors, changing signal
handling etc.

2. Even if you had a spawn() primitive, you would still need both
fork() and exec(), as it's not that uncommon to use them on their own. 
So, a spawn() primitive would have to be in addition to the existing
primitives. This is extra complexity for little gain.

On modern Unices with copy-on-write memory allocation, fork() is
relatively cheap, as it only has to copy the page tables, not the
actual memory.

On older Unices, where fork() copied all of the process' memory, you
would use vfork() for the cases where there wasn't any significant
code in the child branch. Unlike fork(), vfork() doesn't copy the
process' memory. On Linux, vfork() doesn't copy the page tables
either.

Because a child process created by vfork() shares its memory with the
parent, the consequences of modifying memory in the child are
undefined. That makes doing anything other than calling exec() or
_exit() (but not exit()) problematic. In particular, if exec() fails,
you can't recover.

-- 
Glynn Clements <glynn@gclements.plus.com>

Re: fork: why to copy process to run new program?

[Tom]

Hello! :)

Thank you all answers.


Glynn Clements wrote:

> 
> Tom wrote:
> 
>>         Why, when a program needs to open another, have fork to copy all
>>         the
>> initial program just for 'exec' the another? Could'nt initial program
>> just to "tell" the kernel for open the second program?
> 
> I'm not sure what you're getting at.
> 
> If you're asking why fork() and exec() can't be combined into a single
> spawn() primitive, the answer is twofold:

sorry by not clear explanation of my question in prev article.
but I think your answer help to kill my doubt (I say "help" cause I have to
understand more the whole thing before, maybe reading some docs).

but my question could be done so: couldn't processA (example.. bash), when
wants to run processB (example.. ls), just "tell" the kernel (using some
system call, sure) "hey, please, open /bin/ls. Oh, do you need some env
vars? ok, here is the list, PWD=/home/tom, VAR2=VALUE2, etc.. Oh do you
want to know about file descriptos? ok, here is...".

> 
> 1. A spawn() primitive would only handle the simplest cases. It's
> quite common for there to be non-trivial code in the child branch
> before the exec(), e.g. redirecting descriptors, changing signal
> handling etc.
> 
> 2. Even if you had a spawn() primitive, you would still need both
> fork() and exec(), as it's not that uncommon to use them on their own.
> So, a spawn() primitive would have to be in addition to the existing
> primitives. This is extra complexity for little gain.
> 
> On modern Unices with copy-on-write memory allocation, fork() is
> relatively cheap, as it only has to copy the page tables, not the
> actual memory.
> 
> On older Unices, where fork() copied all of the process' memory, you
> would use vfork() for the cases where there wasn't any significant
> code in the child branch. Unlike fork(), vfork() doesn't copy the
> process' memory. On Linux, vfork() doesn't copy the page tables
> either.
> 
> Because a child process created by vfork() shares its memory with the
> parent, the consequences of modifying memory in the child are
> undefined. That makes doing anything other than calling exec() or
> _exit() (but not exit()) problematic. In particular, if exec() fails,
> you can't recover.
> 


Thank you
Tom

Re: fork: why to copy process to run new program?

[Steve Graegert]

Reply inline...

On 7/4/05, Tom <tom.lobato@terra.com.br> wrote:
> 
> Hello! :)
> 
> Thank you all answers.
> 
> 
> Glynn Clements wrote:
> 
> >
> > Tom wrote:
> >
> >>         Why, when a program needs to open another, have fork to copy all
> >>         the
> >> initial program just for 'exec' the another? Could'nt initial program
> >> just to "tell" the kernel for open the second program?
> >
> > I'm not sure what you're getting at.
> >
> > If you're asking why fork() and exec() can't be combined into a single
> > spawn() primitive, the answer is twofold:
> 
> sorry by not clear explanation of my question in prev article.
> but I think your answer help to kill my doubt (I say "help" cause I have to
> understand more the whole thing before, maybe reading some docs).
> 
> but my question could be done so: couldn't processA (example.. bash), when
> wants to run processB (example.. ls), just "tell" the kernel (using some
> system call, sure) "hey, please, open /bin/ls. Oh, do you need some env
> vars? ok, here is the list, PWD=/home/tom, VAR2=VALUE2, etc.. Oh do you
> want to know about file descriptos? ok, here is...".

This is what happens, at least conceptually.  To get a good grasp of
processes and memory management at the kernel level Bovet's and
Cesati's "Understanding the Linux Kernel" (O'Reilly) is highly
recommended.  If you're willing to read online David A. Rusling's "The
Linux Kernel" (http://www.tldp.org/LDP/tlk/tlk.html) is a good start.

> >
> > 1. A spawn() primitive would only handle the simplest cases. It's
> > quite common for there to be non-trivial code in the child branch
> > before the exec(), e.g. redirecting descriptors, changing signal
> > handling etc.
> >
> > 2. Even if you had a spawn() primitive, you would still need both
> > fork() and exec(), as it's not that uncommon to use them on their own.
> > So, a spawn() primitive would have to be in addition to the existing
> > primitives. This is extra complexity for little gain.
> >
> > On modern Unices with copy-on-write memory allocation, fork() is
> > relatively cheap, as it only has to copy the page tables, not the
> > actual memory.
> >
> > On older Unices, where fork() copied all of the process' memory, you
> > would use vfork() for the cases where there wasn't any significant
> > code in the child branch. Unlike fork(), vfork() doesn't copy the
> > process' memory. On Linux, vfork() doesn't copy the page tables
> > either.
> >
> > Because a child process created by vfork() shares its memory with the
> > parent, the consequences of modifying memory in the child are
> > undefined. That makes doing anything other than calling exec() or
> > _exit() (but not exit()) problematic. In particular, if exec() fails,
> > you can't recover.
> >
> 
> 
> Thank you
> Tom

Kind Regards

    \Steve

Re: fork: why to copy process to run new program?

[Glynn Clements]

Tom wrote:

> >>         Why, when a program needs to open another, have fork to copy all
> >>         the
> >> initial program just for 'exec' the another? Could'nt initial program
> >> just to "tell" the kernel for open the second program?
> > 
> > I'm not sure what you're getting at.
> > 
> > If you're asking why fork() and exec() can't be combined into a single
> > spawn() primitive, the answer is twofold:
> 
> sorry by not clear explanation of my question in prev article.
> but I think your answer help to kill my doubt (I say "help" cause I have to
> understand more the whole thing before, maybe reading some docs).
> 
> but my question could be done so: couldn't processA (example.. bash), when
> wants to run processB (example.. ls), just "tell" the kernel (using some
> system call, sure) "hey, please, open /bin/ls. Oh, do you need some env
> vars? ok, here is the list, PWD=/home/tom, VAR2=VALUE2, etc.. Oh do you
> want to know about file descriptos? ok, here is...".

Well, that's essentially what exec() does, but exec() runs the
specified program *in* place of whichever program called exec().

If you want to run a specified program without terminating the current
program, you have to fork() a new process and have the new process run
the program.

-- 
Glynn Clements <glynn@gclements.plus.com>

Re: fork: why to copy process to run new program?

[Ron Michael Khu]

have u tried using system()??

it's a kiddie version of fork and exec...
system() will just let the existing shell execute/interpret the argument 
passed to it.
so u can do something like system("/bin/ls /home"),

but in shell programs like bash, they(the shell programs) are actually 
doing a fork
and an exec everytime u run a program.

take for example this command line:
$ls myDirectory

bash will do a fork() and then do an exec() for ls....
of course commands like "cd ..", "cd ." are just built-in commands, and 
are actually
interpreted solely by the shell program and will no longer require an 
actual exec()

$ls myDirectory | grep myFile
in this command line, bash will perform fork() two times, one for the ls 
command and
one for the grep... the | symbol is a trigger for the bash program to 
invoke another fork
call so that it could actually mimic a pipe-operation.



Tom wrote:

>Hello! :)
>
>Thank you all answers.
>
>
>Glynn Clements wrote:
>
>  
>
>>Tom wrote:
>>
>>    
>>
>>>        Why, when a program needs to open another, have fork to copy all
>>>        the
>>>initial program just for 'exec' the another? Could'nt initial program
>>>just to "tell" the kernel for open the second program?
>>>      
>>>
>>I'm not sure what you're getting at.
>>
>>If you're asking why fork() and exec() can't be combined into a single
>>spawn() primitive, the answer is twofold:
>>    
>>
>
>sorry by not clear explanation of my question in prev article.
>but I think your answer help to kill my doubt (I say "help" cause I have to
>understand more the whole thing before, maybe reading some docs).
>
>but my question could be done so: couldn't processA (example.. bash), when
>wants to run processB (example.. ls), just "tell" the kernel (using some
>system call, sure) "hey, please, open /bin/ls. Oh, do you need some env
>vars? ok, here is the list, PWD=/home/tom, VAR2=VALUE2, etc.. Oh do you
>want to know about file descriptos? ok, here is...".
>
>  
>
>>1. A spawn() primitive would only handle the simplest cases. It's
>>quite common for there to be non-trivial code in the child branch
>>before the exec(), e.g. redirecting descriptors, changing signal
>>handling etc.
>>
>>2. Even if you had a spawn() primitive, you would still need both
>>fork() and exec(), as it's not that uncommon to use them on their own.
>>So, a spawn() primitive would have to be in addition to the existing
>>primitives. This is extra complexity for little gain.
>>
>>On modern Unices with copy-on-write memory allocation, fork() is
>>relatively cheap, as it only has to copy the page tables, not the
>>actual memory.
>>
>>On older Unices, where fork() copied all of the process' memory, you
>>would use vfork() for the cases where there wasn't any significant
>>code in the child branch. Unlike fork(), vfork() doesn't copy the
>>process' memory. On Linux, vfork() doesn't copy the page tables
>>either.
>>
>>Because a child process created by vfork() shares its memory with the
>>parent, the consequences of modifying memory in the child are
>>undefined. That makes doing anything other than calling exec() or
>>_exit() (but not exit()) problematic. In particular, if exec() fails,
>>you can't recover.
>>
>>    
>>
>
>
>Thank you
>Tom
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>  
>