Why fork and exec saved 2 separate calls

I understand the differences between fork, vfork, exec, execv, execp. So pls not rant about it. My question is about the design of creating a unix process. Why did designers think about creating two separate calls (fork and exec) instead of keeping it in one hard call (spawn). Was a good API design a reason for developers to have more control over the creation process? Is this due to a performance reason, so that we could delay the distribution of the process table and other kernel structures to the child until copy to write or copy on access is done?

+8
unix process kernel fork
source share
4 answers

The main reason is that the separation of the fork() and exec() steps allows arbitrary configuration of the child environment to make other system calls. For example, you can:

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

... and much more. If you combined these calls into a single spawn() call, it had to have a very complex interface so that it could code all these possible changes in the child environment - and if you ever added a new parameter, the interface had to be changed. On the other hand, the separate fork() and exec() steps allow you to use regular system calls ( open() , close() , dup() , fcntl() , ...) to control the child environment before exec() . New functionality (e.g. capset() ) is easily supported.

+5
source share

fork and exec do completely different things.

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

There are many reasons to use one without the other. You can unlock the child processes that perform tasks on behalf of your controlling parent application, for example, quite common in the unix world. And you can, for example, set up prerequisites for some other fancy application, and then execute it from the launch application without using fork.

+4
source share

AFAIK, initially there was only fork (). But performance considerations prompted the creation of exec (), which does not recreate the kernel structures that will be immediately overwritten. <- This is not true.

Where a process is required, a performance problem arises that creates a child process that is not a copy of itself. The fork () function copies kernel-related process data, which will be immediately replaced by exec (). Thus vfork () , which does not copy excessive kernel data and any process data; after it, the process is expected to call something exec () - like, and the parent will be paused until the child does this. However, see the Errors section for a description of issues with vfork ().

0
source share

fork () can only be used to create a child process. Only parent replication can be performed. Although exec () can be used to start any new process on the system. I do not see any correlation above two.

-2
source share

All Articles