Menu
I understand the differences between fork, vfork, exec, execv, execp. So pls dont rant about it. My question is about the design of the unix process creation. Why did the designers think of creating 2 seperate calls ( fork and exec ) instead of keeping it one tight call ( spawn ). Was good API design a reason so that developers had more control over process creation? Is it because of performance reason, so that we could delay allocating process table and other kernel structures to the child till either copy-on-write or copy-on-access?
835
fork vs execfork starts a new process which is a copy of the one that calls it, while exec replaces the current process image with another (different) one. Both parent and child processes are executed simultaneously in case of fork() while Control never returns to the original program unless there is an exec() error.
A program that calls exec() without fork() is chain loading, overlaying its process with a different program image. There is a whole subculture of chain loading utilities that do particular things to process state and then execute another program to run with that revised process state.
fork() creates a new process, which is a copy of the parent process. So if you did only fork() , you would have two identical processes running. Therefore in order to replace the forked process with another code, you need to perform exec() which replaces the currently running process with the specified executable file.
This leads to more efficient memory usage. Question 7: [6 points] In terms of call-return behavior, how are the fork() and exec() system calls different from other system/function calls? Ans: fork(), if successful, returns twice – once in the parent and once in the child. Exec() never returns, if successful.
The main reason is likely that the separation of the fork() and exec() steps allows arbitrary setup of the child environment to be done using other system calls. For example, you can:
...and many more besides. If you were to combine these calls into a single spawn() call, it would have to have a very complex interface, to be able to encode all of these possible changes to the child's environment - and if you ever added a new setting, the interface would need to be changed. On the other hand, separate fork() and exec() steps allow you to use the ordinary system calls (open(), close(), dup(), fcntl(), ...) to manipulate the child's environment prior to the exec(). New functionality (eg. capset()) is easily supported.
189
fork and exec do completely different things.
There's plenty of reasons to use one without the other. You can fork off child processes that perform tasks on behalf of your controlling parent app e.g., pretty common in the unix world. And you can e.g. setup the preconditions for some other quirky application and then exec it from your launcher application without ever using fork.
22
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
