I have some thought on this topic. I don't see any inventors of Unix said why the fork-model was chosen exactly. But I believe the fork well conforms to some basic Unix principles, if not intently, at least coincidently and so be persevered by natural selection over time.
Among other principles, Unix has two important principles,
1. Each component should do one thing, and do one thing well.
2. Fundamental component (especially like kernel) should provide mechanism rather than policy.
Among the kernel's jobs, to create a new task and to decide what new job the new task should do are two separate things. Although most of newly-created task is to load another executable from the disk, but that's not always the case. A newly-created task may run the same code as its parent, with the same or different input, or it may load new executable code from network or other media than disk, or it may even compute new code by its own.
Therefore to implement a system call that creates a new task AND loads new executable code is a bad idea. If you insist to do so, you come across the second difficulty that is how you determine the way the new executable code is loaded. To enforce the new code always loaded from disk is crude. To provide several predefined way is better, but still it enforces policy to users.
On the other hand, to create an empty task is also not practice. Can an empty task exist at all? I don't know. But how an empty task decide what it go next step. It can't. So either kernel or another task should make decision for it. Kernel should not provide policy so it shouldn't make such a decsion. Another task doing so will violate process separation basically. To let the newly-created task duplicate its parent is a handy and elegant choice. It involves only memory operation (and by COW the memory opt is also minimized). It does not violate process separation and make the child-process have maximal flexibility to decide what next step to go. So fork() does one thing only and well and push as much policy as possible up to the user space.
OK, at last, after all, to load a new executable from disk is a usual operation so Unix provides exec(). But be aware two things,
1. exec() is one of the many choices you can do after a fork().
2. To be invoked after fork() is one of the many cases exec() is used.
exec() does not necessarily pair with fork(). That single point actual proven it is completely correct to separate them. They are orthogonal. And orthogonality is the most beautiful things science and engineering pursue.
And again, I don't read anything like above from the history or stories of Unix. It is completely my own understanding from the articles and words spread in several books and many web pages plus the result of my own crude mental activities. Hope it answer you questions.
2008/5/25 Peter Teoh <htmldeveloper@xxxxxxxxx>:
i can see that there are not many specific questions here....just
asking "why".....and speaking of concepts...
personally...i think knowing WHY things are done the way it is done is
more impt than knowing the details of HOW....but then it is chicken
and egg...until u know how they are done....then u began to ask
WHY....once u understood that.....design your own ideas based on new
understanding...
but life is a game of probability.....so probabilistically...i think u
will gain more and contribute more if u trying understanding HOW AND
WHY things are done concurrently....while at the same fallback on
design your own ideas once in a while.....
i can summarize a few key FEATURES or PROBLEMS u must have / solved,
in multiprocessor/multi-users/multiprocess user/process management
system (as for the current design....i really wish u or someone else
will overhaul the entire design of UNIX.....):
a. u don't want them to step on each other's memory.....which is one
of the hidden reason for separation of memory space during forking...
b. after forking...different process is will be protected via INTEL
CPU HARDWARE feature.....there are many....and u have to design the OS
to follow all these hardware features...(one of them is MMU, then task
register, context switching, memory page attributes protection etc)
c. efficiency of execution....minimization of resources
(copy-on-write design)...performance tradeoff between harddisk storage
vs memory storage....(swapping)....
Generally the field is huge....and endless argument ....and I have to
stop here....
PS: Get hold of "The Magic Garden Explained".....my all-time
favorite on OS design..
Regards,
On Sun, May 25, 2008 at 1:05 AM, William Case <billlinux@xxxxxxxxxx> wrote:
> Hi Peter;
>
> On Sat, 2008-05-24 at 23:34 +0800, Peter Teoh wrote:
>> On Sat, May 24, 2008 at 11:31 PM, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote:
>> > Sent on behalf of William Case:
>> >
>> > From: William Case <billlinux@xxxxxxxxxx>
>> > Date: Sat, May 24, 2008 at 11:26 PM
>> > Subject: fork and exec
>> >
>> > Hi;
>> >
>> > I have a fundamental question about why Linux/Unix uses the parent and
>> > child modal to start and run new processes.
>> >
>> >
> [snip]
>
>
>> > My question is: Why did the original designers of Multics/Unix choose
>> > to use the forking modal to start a new processes? Do not other OSs use
>> > other modals? What problem(s) did the fork overcome? Couldn't a system
>> > have been designed that just (in some way) starts each process raw?
>>
>> can u elaborate what is meant by "RAW"??
>>
> I was using the word "raw" simply as a metaphor for a process that is
> directly placed in memory and accessed without first copying a parent or
> being overlaid on a space (buffer) created by a child.
>
> Two possibilities come to mind:
>
> 1) Starting a process the same way that PID 0 (swap ??) is started, or,
> 2) Starting a process the way that other Operating Systems start a
> process.
>
> In 2) above, I don't know how other OSes might start their processes but
> everything I have read about Unix related systems *implies* that the
> parent-child relationship is unique to or central to *nixes. I.e other
> OSes must be doing it differently.
>
>
>> I like new ideas....please elaborate....things necessarily have to be
>> different all the time.....that's how Windows can survive in
>> business....
>>
>> > Intuitively, copying a process then overwriting it seems wasteful or at
>> > least inelegant, so why is it needed? How does a parent-to-child
>> > process enhance its (*nix's) design philosophy?
>> >
>> > Since forking is at the very core of the kernel, I would like to
>> > understand intellectually why the fork process is necessary?
>> >
> Once again, I am not asking how it is done. I am asking why. Is the
> parent-child relationship used because there is, in fact, no other way
> to do it? If so why does the claim seem to be made that parent-child
> processing is unique to *nixes?
>
>> > I am not being argumentative, or trolling, or proposing something
>> > different or better. Although relatively new to kernel programming and
>> > 'C' I am not a complete newbie. I would just like to see in my
>> > minds-eye what is going on and *why*.
>> >
>> > --
>> > Regards Bill
>> >
> As I read various manuals, read books on the Linux Kernel source code,
> and prepare my machine for a virtual Linux system that I can explore and
> play with. This fork question, WHY?, keeps niggling at me and in some
> ways makes it harder for me to concentrate on the longer view of what is
> happening in the kernel.
>
> --
> Regards Bill
>
>
--
Peter Teoh
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
