UNIX for Dummies Questions & Answers

Hi!

Can someone explain me exactly this technique? Why a process (PARENT) creates a copy of itself with FORK (CHILD)? What's the reason of this behaviour? Sorry, but I cannot understand the logic behind it.

Thanks.

I don't really understand this question. But let's say you have a process running that is a shell. A user has entered the command "date". So no wthe shell would like to run the separate program called "date" and display the results to the user. So the shell will fork and exec the date program. Why? Because that is the only game in town. There is no other way for it to run another program. Either it can fork/exec and thus run the program or it can tell the user "sorry I don't know how to run programs".

thank you for your answer but i'm sorry, i still dont understand this concept.
if I call on the shell the program 'date', you say that the shell, parent process (right?) will fork itself (?) creating a child shell that will execute the date command...now what I don't understand clearly is why not executing directly without forking, so without creating a copy (child) of itself...
hope i made it clearer now and sorry...it might seem a stupid question or not very clearly formulated, but i am new to unix.
thanks.

Shell is a different process,
and the new process that the shell should run is an entirely different one.

As process entities the shell and the new process that should run are different entities.

So to run a process, we need process space and the process binary for it to go.
Hence, the parent process shell creates the process space (fork) and in the new process space, the requested process which should run which is done by exec - overlaying the image of the binary that is to be run.


Any mistakes/modifications please correct them !

First, as I said the reason for the fork/exec in the shell is that there is no other way. Now I think I see your question... why doesn't the kernel has a spawn_process() system call to provide an alternative to fork/exec. Since I did not design the kernel, I don't know the definitive answer. But I can speculate. First both fork() and exec() are needed. For example an ftp server must fork a copy of itself to handle each new connection. Threads now provide an alternate, but threads are new and an OS without a fork() would be missing an important capability. exec is even more fundamental and almost all OS's will have an exec capability. For example, a login program will exec a shell. Another separate spawn_process() system call would expand the kernel. Originally unix was run on systems with only a few kilobytes of memory. The added cost of a separate system call could not be tolerated. It does seem like a waste to copy an entire process and then a few instructions later invoke exec to replace it. This bothered everyone a little bit and as unix evolved, the addition of shell scripts hightened the concern since unix was forking more often. Meanwhile memory sizes were increasing. Also a version of unix was being developed at Berkeley and the Berkeley guys loved shoving stuff into the kernel. They added vfork(). With vfork, a process pretends to copy itself. The parent hangs and the child runs. When the child execs, the parent is free to run. No more copying those large data regions. vfork() tends to still be available, but fork() was souped up. These days a fork() does not copy the process. Both processes simply more forward using the same image. If either process wants to change something, that page is copied. This is called copy-on-write. Some architectures cannot handle this so they use copy-on-access instead which is almost as good. And neither process stalls as with vfork(). So fork() can now out-perform vfork() in many cases. This eliminates most of the overhead you may be perceiving with fork/exec.

Again these days, most stuff will be shared by the two processes so very little new stuff pops into existence at fork time. exec overlays these structures that define the process. But you may be surprised here. Suppose that we have a case of a "login" doing a fork/exec for ksh. There probably is already a ksh running somewhere on the system. We simply point to its text segment. If this is the first ksh, the structures that define the process are empty. As it runs, the pages it needs will not be there. So a page fault will occur and the page will be loaded. So ksh will page fault its way into core and only the parts of the program actually used will come in. In each case, ksh will probably be using shared libraries which are already in core. So not that much happens during an exec() either. Entire processes are never copied nor loaded. Both fork and exec are very fast now.

To be complete, Linux has clone() and clone2() system calls which are a bit like vfork() was. But these clone calls are intended for internal use only and then only to implement threads.