Who know the history of unix fork?

Fork is a great tool in unix.We can use it to 开发者_C百科generate our copy and change its behaviour.But I don't know the history of fork.

Does someone can tell me the story?

Actually, unlike many of the basic UNIX features, fork was a relative latecomer ^(a).

The earliest existence of multiple processes within UNIX consisted of a few (fixed number of) processes, one per terminal that was attached to the PDP-7 machine ^(b).

The basic idea was that the shell process for a given terminal would accept a command from the user, locate the program file, load a small bootstrap program into high memory and jump to it, passing enough details for the bootstrap code to load the program file.

The bootstrap code, after loading the program into low memory (overwriting the shell), would then jump to it.

When the program was finished, it would call exit but it wasn't like the exit we know and love today. This exit would simply reload the shell and run it using pretty much the same method used to load the program in the first place.

So it was really more like a rudimentary exec command, the one that replaces your current program with another, in the same process space.

The shell would exec your program then, when your program was done, it would again exec the shell by calling exit.

This method was similar to that found in many other interactive systems at the time, including the Multics from whence UNIX got its name.

From the two-way exec, it was actually not that big a leap to adding fork as a process duplicator to work in conjunction. While many systems run another program directly, it's this "just add what's needed" method which is responsible for the separation of duties between fork and exec in UNIX. It also resulted in a very simple fork function.

If you're interested in the early history of various features^(c) of Unix, you cannot go past the article The Evolution of the Unix Time-Sharing System by Dennis Ritchie, presented at a 1979 conference in Australia, and subsequently published by AT&T.

^(a) Though I mean latecomer in the sense that the separation of the four fundamental forces in the universe was "late", happening some 0.00000000001 seconds after the big bang.</humour>.

^(b) Since a question was raised in a comment as to how the shells were originally started off, there's a great resource holding very early source code for Unix over at The Unix Heritage Society, specifically the source code archives and, in particular, the first edition.

The init.s file from the first edition shows how the fixed number of shell processes were created (slightly reformatted):

    ...
    mov    $itab, r1        / address of table to r1
1:
    mov    (r1)+, r0        / 'x, x=0, 1... to r0
    beq    1f               / branch if table end
    movb   r0, ttyx+8       / put symbol in ttyx
    jsr    pc, dfork        / go to make new init for this ttyx
    mov    r0, (r1)+        / save child id in word offer '0, '1, etc
    br     1b               / set up next child
1:
    ...

itab:
    '0; ..
    '1; ..
    '2; ..
    '3; ..
    '4; ..
    '5; ..
    '6; ..
    '7; ..
    0

Here you can see the snippet which creates the processes for each connected terminal. These are the days of hard-coded values, no auto detection of terminal quantity involved. The zero-terminated table at itab is used to create a number of processes and hopefully the comments from the code explain how (the only possibly tricky bit is the labels - though there are multiple 1 labels, you branch to the nearest one in a given direction, hence 1b means the closest 1 label in the backwards direction).

The code shown simply processes the table, calling dfork to create a process for each terminal and start getty, the login prompt. The getty program, in turn, eventually started the shell. From that point, it's as I described in the main part of this answer.

^(c) No paths (and use of temporary links to get around this limitation), limited processes, why there's a GECOS field in the password file, and all sorts of other trivia, generally interesting only to uber-geeks, of course.