All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom <tom.lobato@terra.com.br>
To: linux-c-programming@vger.kernel.org
Subject: Re: fork: why to copy process to run new program?
Date: Mon, 04 Jul 2005 08:46:26 -0300	[thread overview]
Message-ID: <dab7ij$fs7$1@sea.gmane.org> (raw)
In-Reply-To: 17096.39828.119917.882703@gargle.gargle.HOWL


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


  reply	other threads:[~2005-07-04 11:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-04  1:09 fork: why to copy process to run new program? Tom
2005-07-04  2:01 ` Ron Michael Khu
2005-07-04  2:14 ` Glynn Clements
2005-07-04 11:46   ` Tom [this message]
2005-07-04 12:09     ` Steve Graegert
2005-07-04 14:51     ` Glynn Clements
2005-07-05  3:00     ` Ron Michael Khu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='dab7ij$fs7$1@sea.gmane.org' \
    --to=tom.lobato@terra.com.br \
    --cc=linux-c-programming@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.