Talk:Fork (system call)

message: 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)
replies: text: 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)
thread_title:  Mythos 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Make code compileable 

message: 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)
thread_title:  SMP 

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

message: This page is good and helps me on how to program fork in C.
But I would suggest first to put the discussion of more technical aspects like vfork in a separate page.
Secondly, could some more examples in C be provided? What about communication between forked processes for example.  —Preceding unsigned comment added by 161.53.128.59 (talk) 09:01, 21 August 2009 (UTC)
thread_title:  Splitting of section 

message: Prior content in this article duplicated one or more previously published sources.  Copied or closely paraphrased material has been rewritten or removed and must not be restored, unless it is duly released under a compatible license. (For more information, please see "using copyrighted works from others" if you are not the copyright holder of this material, or "donating copyrighted materials" if you are.) For legal reasons, we cannot accept copyrighted text or images borrowed from other web sites or published material; such additions will be deleted. Contributors may use copyrighted publications as a source of information, but not as a source of sentences or phrases. Accordingly, the material may be rewritten, but only if it does not infringe on the copyright of the original or plagiarize from that source. Please see our guideline on non-free text for how to properly implement limited quotations of copyrighted text. Wikipedia takes copyright violations very seriously, and persistent violators will be blocked from editing. While we appreciate contributions, we must require all contributors to understand and comply with these policies. Thank you.  Osiris (talk) 07:02, 7 July 2012 (UTC)
thread_title:  Copyright problem removed 

message: At least with POSIX threads, forking a process creates a process with a single thread, i.e. only the thread that called fork(2) is duplicated, see e.g. Is it safe to fork from within a thread? or Chapter 6 in David R. Butenhof's book "Programming with POSIX Threads". Should the article mention this or would this be out of scope? — Tobias Bergemann (talk) 13:39, 8 August 2013 (UTC)
thread_title:  Fork only duplicates the calling thread 

message: The section "Importance of forking in Unix" claims (without a source) that
:Forking is an important part of Unix, critical to the support of its design philosophy
I don't think this is true. The ability to run multiple programs is critical to the Unix philosophy, and for that matter to any multiprocessing operating system. The section does have a point when it describes the combination of forks and pipes, which is quite simple in Unix but then again, (1) fork is older than pipe (V1 vs. V3 Research Unix, IIRC) and (2) the pipelining mechanism could have been implemented in a different way, e.g. by a combined fork/exec system call that can also set file descriptors. Maybe that would violate worse is better, but I see nothing particularly important about fork for the support of shell pipelines. QVVERTYVS (hm?) 14:08, 16 October 2013 (UTC)
thread_title:  Importance of forking in Unix 

message: It is mentioned that vfork() was first appeared in 3BSD, but FreeBSD's manual page claims that vfork() was first appeared in 2.9BSD. Stevens and Rago in the Advanced Programming in the Unix Environment also claim that vfork() was originated from 2.9BSD (p. 234). I think this conflict arises from that the vfork() system call was removed in 4.4BSD (according to Stevens and Rago), but later systems added it back (as mentioned in the Linux manual page). -- Bkouhi (talk) 02:35, 14 March 2015 (UTC)
replies: text: Seems like they're wrong. 3BSD has a  manual page, and 3BSD predates 2.9BSD by four three years. (The 2.9 series was continued into the 1990s, though not by Berkeley; 2.9 was a 4.1cBSD backported to the PDP-11.) The NetBSD people know this too. QVVERTYVS (hm?) 11:39, 14 March 2015 (UTC)
thread_title:  Origin of vfork() 

message: Quoting Bach does not seem to be a good idea for giving citations for the relevance of vfork(). Bach did never really use vfork()...
You should rather ask people who implemented vfork() in a shell and did performance analysis on the results. So rather ask Bill Joy, David Korn or me. vfork() is still 3x faster than the COW based fork() introduced by SunOS-4.0 that is now available in SVr4 as well. Schily (talk) 12:51, 23 October 2015 (UTC)
thread_title:  Wrong text for vfork() in the article 

message: According to project genie fork originated there. The two articles should be reconciled. (I do not understand why the preview shows project genie as a missing article.)
"The fork mechanism (1969) in Unix and Linux maintains implicit assumptions on the underlying hardware". This sentence
is self-contradictory. The listed assumptions did not hold for the hardware on which Unix ran in 1969 and some years after. Mdmi (talk) 06:10, 3 January 2016 (UTC)
replies: text: It's spelled Project Genie; article titles are case-sensitive except that the first character is capitalized automatically. You're right about the hardware requirements: paging (VM) Unix post-dates fork by a decade. Removed that. QVVERTYVS (hm?) 15:38, 3 January 2016 (UTC)
thread_title:  fork in other operating systems 

message: Just for your information: Linux is not a POSIX OS and what Linux does is not a gauge for POSIX OS.
A fast posix_spawn() needs vfork() and that a posix_spawn() implemented on top of fork() is a slow and useless restriction.
If you like to do a decent comparison of fork() and vfork(), you need to check an OS that implements a modern fork() and a vfork().
Solaris implements both fork variants:
* the new copy on write fork() call, that was invented by SunOS-4.0 in late 1987.
* the traditional vfork() that shares MMU descriptors instead of sharing memory in the fork() above.
Vfork() is still 2.6x faster than the new copy-on-write fork() for the recent version of the Bourne Shell (160kB size) on my home machine. This causes a noticeable speed-up for "configure" compared to an old non-vfork() aware Bourne Shell.
Note that there are currently 4 known shells that support vfork: 
* csh - the first - vfork was written for csh before 1980
* my bsh uses vfork since 1985
* ksh93 uses vfork since ~ 1993
* The recent Bourne Shell uses vfork since 2014
The shells using vfork() are noticeable faster than other shells. Schily (talk) 13:47, 5 January 2016 (UTC)
replies: text: Who says we're restricting our attention to POSIX-compliant OS's? The source finds Linux important enough to mention it; the Solaris source code is not enough to establish one implementation strategy as "typical". QVVERTYVS (hm?) 14:05, 5 January 2016 (UTC)
replies: text: Didn't you read the article? It mentions that vfork() was removed from POSIX. BTW: You are welcome to present source code for other POSIX certified implementations (e.g. AIX). Schily (talk) 14:08, 5 January 2016 (UTC)
thread_title:  posix_spawn() based on fork is slow 

message: I think double fork is a notion that should be mentioned. The attempt I am aware of is at line 110 at https://en.wikipedia.org/w/index.php?title=Fork_%28system_call%29&action=historysubmit&type=revision&diff=748268941&oldid=748250332
— Preceding unsigned comment added by 188.120.133.176 (talk) 14:47, 7 November 2016 (UTC)
thread_title:  double fork 

message: https://dl.acm.org/doi/abs/10.1145/3317550.3321435  — Preceding unsigned comment added by 66.25.27.1 (talk) 03:55, 28 June 2022 (UTC)
replies: text: Perhaps - see also this - (provided that it doesn't devolve into yet another mess.  There are a few related sources (see this), but so far no third-party sources which contrast those. TEDickey (talk) 07:58, 28 June 2022 (UTC)
thread_title: Should add reference to Microsoft's "A fork in the road" paper

message: There's a quote from version 3.something of the Linux kernel manpages, which isn't in release 5.  Actually (see change) that was removed silently in 2012. The link could be repaired, e.g., with this, or trimmed. TEDickey (talk) 22:45, 25 November 2019 (UTC)
thread_title: unfortunate, etc