Talk:Fork (operating system)

From Wikipedia, the free encyclopedia

http://www.electrictoolbox.com/article/php/process-forking/

Contents

[edit] Fork is not critical to the Unix design philosophy

Forking is an important part of Unix, critical to the support of its design philosophy, which encourages the development of filters.

Concurrent processes are necessary for the development of filters. Whether they are implemented using fork, or some other primitive such as spawn, is surely an implementation detail? --DavidHopwood 18:26, 5 April 2007 (UTC)

Yet fork predates spawn by at least a decade or two. I'll wager that many Unix programmers don't even know there is a spawn function. Likewise, a huge amount of Unix code relies on fork/exec to operate. — Loadmaster 03:51, 20 June 2007 (UTC)
No, I don't think it is just an implementation detail. I believe 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 ways is better, but still it enforces policy to users.
On the other hand, to create an empty task is also not practical. 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 has to make a decision for it. Kernel should not provide policy so it shouldn't make such a decision. 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. — Feng Dong 11:44, 28 May 2008 (+0800)

[edit] Mythos

What about deleting that paragraph? I'm not sure whether the author was aware of the fact that he described the infamous "forkbomb" which has its own article and is already linked below. Further "mythos" is never actually explained. Also I doubt this is the right place for "honorable mentions" of fork() or whatever else. There would be no end if you did this for all articles. If at all, the article about the Matrix should link to fork but not vice-versa. Anyway, I remove it from the article. --82.141.49.144 03:55, 4 December 2005 (UTC)

While I agree with much of this, rather than saying mythos, I think that "geek culture" is probably a bit better, as the term has seeped into "pop" culture. McKay 00:07, 9 December 2005 (UTC)

[edit] Make code compileable

I can't compile the code. Someone could add the propriate header files. It invite readers to experiment with fork(). The line with the /* Note */ should be changed and the note should be removed. I have no clue what the author meant with that. --Bernard François 14:58, 15 January 2006 (UTC)

From what I can see this code only needs the unistd.h (or stdlib.h if that doesn't work) header file, sometimes it also needs an extra include such as /sys/type.h or /sys/types.h, but this is sytem dependent. Also, the code should be in a main function. I'm not going to change the code on the page because it is only sample code. Regarding the /* Note... */, this line uses _exit(), which is different from exit(), (it has no underscore). These things may be effectively the same (actually they probably are - an exit() works fine here), but you'd need to see the source code for each of them. --Pyrofysh 06:36, 25 April 2006 (UTC)
But why did the author use _exit() instead of exit() at all in the child? --84.188.202.21 14:31, 12 October 2006 (UTC)
The standard library does some clean-ups with library call exit() (flushes buffers, closes file descriptors). Also, any files created with tmpfile() are closed, and some other things may occur also that one would prefer not to happen until the parent exits. The system call _exit() unconditionally exits. In addition, had vfork() been used instead of fork(), very unexpected things can happen because the memory is shared, if exit() is called before an exec; but sensible people don't use vfork. Agarvin 20:03, 12 November 2006 (UTC)

[edit] SMP

Forks fully utilize SMP, right?

If you mean Symmetric MultiProcessing, this depends more on the operating system's implementation of process handling than on the fork call. All fork does in most implementations is make a copy of a current process. --Pyrofysh 06:41, 25 April 2006 (UTC)

[edit] Clean code

Why is there a declaration of "int i" at the start of the code when it is only used in one of the for loops? Why not declare int i & j at the start, and forget about "i" at the beginning? Consistency? Maybe I am missing something?

Nope, not missing anything - this is fixed. Steeltoe 05:13, 19 April 2006 (UTC)
On that note, some compilers will not compile the code unless all variables are intialised at some point in the function. Currently i is only initialised under the "else if(pid <0)" condition, and j is only intialised under the "if(pid==0)" condition. As neither of these variables will be initialised under all cases, those compilers will cause an error. Ideally both int i and j should be declared at the start, because c intialises ints on declaration (even if it sometimes is to nonsense).
I'm just putting this note here in case someone doesn't understand why their code doesn't compile - I think that the current code should remain unchanged regarding this because it is simpler having variables declared where they are used (in this case), additionally, most modern compilers don't suffer from this problem. --Pyrofysh 10:22, 7 June 2006 (UTC)

[edit] exit()

I've created an article for the inverse operation, exit. - Loadmaster 16:36, 18 August 2006 (UTC)

[edit] Merge with Fork Paging

It has been suggested to merge Fork Paging with this article. Add your comments below.

  • Merge. The paging article appears to be somewhat unnecessary. Its content should be reduced to its essentials and merged with this (main) article. — Loadmaster 03:49, 20 June 2007 (UTC)