why fork and exec are kept 2 seperate calls

Question

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?

Answer 1

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:

• Set up an arbitrary set of open file descriptors;
• Alter the signal mask;
• Set the current working directory;
• Set the process group and/or session;
• Set the user, group and supplementary groups;
• Set hard and soft resource limits;

...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.

Answer 2

fork and exec do completely different things.

• fork() - duplicates a process
• exec() - replaces a process

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.