In Unix whenever we want to create a new process, we fork the current process i.e. we create a new child process which is exactly the same as the parent process and then we do exec system call to replace the child process with a new process i.e. we replace all the data for the parent process eith that for the new process. Why do we create a copy of the parent process in the first place and why don't we create a new process directly? I am new to Unix please explain in lay-man terms.

  • 1
    There's a stackexchange site for unix/linux: unix.stackexchange.com I'm not sure if which site is more appropriate for this question so I'll flag for moderator attention. – FrustratedWithFormsDesigner Jun 11 '14 at 17:39
  • @FrustratedWithFormsDesigner: fork() is part of POSIX.1. While that standard has roots in Unix, enough other systems implement it that it really isn't Unix-specific. – Blrfl Jun 11 '14 at 19:19
  • @Blrfl: Ok. I wasn't sure if the implementation varied enough to warrant migration to the unix/linux site. It sounds like it's better off here, if it's general enough. – FrustratedWithFormsDesigner Jun 11 '14 at 19:22

By separating fork() and execve() you let the parent control the environment that the child inherits.

The most common example is the shell redirecting IO, for example in the following command:

find . -name '*.java' | grep Frob

In this example, the standard output of find is attached to the standard input of grep. These are two distinct file descriptors, which are in-memory objects.

In a world where fork and exec are separate, the shell contains code that re-assigns file descriptors in the forked child, before exec-ing the new program. In a world where fork and exec are separate, you would need some sort of mechanism to pass this information to the child program, perhaps via some "well-known" shared memory ID.

The former (fork/exec) model is a lot simpler to implement, and allows a default case where the parent and child share many of the same resources.

  • 1
    If you'd like some history, go here and read the section "Process Control" (read the entire thing, it's worth it). – kdgregory Jun 11 '14 at 19:22
  • I don't think this gives the rationale behind separating fork & exec. A lot of time processes fork then exec. Because today most fork implementations are variations of rfork(), it's no longer simple. Otoh, for programmers, using posix_spawn() is simpler when all they want to do is just execute another program. vfork() also serves as example to fork() is not that simple. Also with your example, you don't need fork and you don't need reassigning file description, they only need to have stdio open. – imel96 Jun 11 '14 at 23:57
  • 1
    @imel96 Uh, yes, the shell does need to change the file descriptors so stdout of find goes to stdin of grep... Otherwise output will just continue to go to the terminal's stdout, that it inherited from the shell. – Izkata Jun 12 '14 at 4:15
  • Update of @kdgregory link bell-labs.com/usr/dmr/www/hist.html – hauptmech Jan 19 '16 at 6:29

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.