A question about execv and process family relationship

Question

After a process forks and the forked son invokes execv, is the result still the son of the father?

Answer 1

Yes it is. Also the terminology "process family" is uncomfortably close to "process group" which is quite an important concept.

Answer 2

Yes. execv doesn't create a new process - that's why you need to fork first.

Answer 3

fork creates a new process called the CHILD of the PARENT.....exec replaces the current running program with the process exec'd and therefore remains the CHILD process of the PARENT...

Answer 4

You're on the right track. Basically, the fork(2) system call in in old UNIX created a copy of the process that forked, with a new PID and a new process stack, copying the memory space to do it. The exec loads the existing process with a new image. You can see one version of that in the exec operation in most shells -- it uns the desired image in the process that was occupied by the shell.

When you fork a process, the fork system call returned the PID of the new process, if you're the parent, or 0 if you're the child. The child process also inherits all open file descriptors, in particular 0,1, and 2, which are more commonly known as STDIN, STDOUT, and STDERR.

(Pop quiz: how do you suppose a shell manages redirection, eg with >?)

More modern UNIX variants with larger address spaces (the original UNIX only had 64K words total!) implementa variant fork called vfork that only copies the necessary subset of the process to start running, and depends on the memory manager to pull in the rest if needed. Since most times fork is immediately followed by exec, which needs to load a new image anyway, this is a significant optimization.

Mach takes that a step further; when you create a new pprocess, nothing is copied except what you need for an execution context; the image is exactly the same. Copying only happens when the process changes a location in memory, at which point the page containing that location is copied. This is called "copy on write", and is nearly optimal.