Процестің көшірмесін жасау: "Fork" операциясы

In computing, an operation whereby a process creates a copy of itself
In computing, particularly in the context of the Unix operating system and its workalikes, fork is an operation whereby a process creates a copy of itself. It is an interface which is required for compliance with the POSIX and Single UNIX Specification standards. It is usually implemented as a C standard library wrapper to the fork, clone, or other system calls of the kernel. Fork is the primary method of process creation on Unix like operating systems.

In multitasking operating systems, processes (running programs) need a way to create new processes, e. g. to run other programs. Fork and its variants are typically the only way of doing so in Unix like systems. For a process to start the execution of a different program, it first forks to create a copy of itself. Then, the copy, called the "child process", calls the exec system call to overlay itself with the other program: it ceases execution of its former program in favor of the other. The fork operation creates a separate address space for the child. The child process has an exact copy of all the memory segments of the parent process. In modern UNIX variants that follow the virtual memory model from SunOS 4.0, copy on write semantics are implemented and the physical memory need not be actually copied. Instead, virtual memory pages in both processes may refer to the same pages of physical memory until one of them reads from such a page: then it is copied. This optimization is important in the common case where fork is used in conjunction with exec to execute a new program: typically, the child process performs only a small set of actions before it ceases execution of its program in favour of the program to be started, and it requires very few, if any, of its parent's data structures. When a process calls fork, it is deemed the parent process and the newly created process is its child. After the fork, both processes not only run the same program, but they resume execution as though both had called the system call. They can then inspect the call's return value to determine their status, child or parent, and act accordingly.

One of the earliest references to a fork concept appeared in A Multiprocessor System Design by Melvin Conway, published in 1962. Conway's paper motivated the implementation by L. Peter Deutsch of fork in the GENIE time sharing system, where the concept was borrowed by Ken Thompson for its earliest appearance in Research Unix. Fork later became a standard interface in POSIX.

The child process starts off with a copy of its parent's file descriptors. For interprocess communication, the parent process will often create one or several pipes, and then after forking the processes will close the ends of the pipes that they do not need.

Vfork is a variant of fork with the same calling convention and much the same semantics, but only to be used in restricted situations. It originated in the 3BSD version of Unix, the first Unix to support virtual memory. It was standardized by POSIX, which permitted vfork to have exactly the same behavior as fork, but was marked obsolescent in the 2004 edition and was replaced by posix spawn (which is typically implemented via vfork) in subsequent editions. When a vfork system call is issued, the parent process will be suspended until the child process has either completed execution or been replaced with a new executable image via one of the "exec" family of system calls. The child borrows the memory management unit setup from the parent and memory pages are shared among the parent and child process with no copying done, and in particular with no copy on write semantics;

Similarly, the Linux man page for vfork strongly discourages its use: but the POSIX specification notes that they were "designed as kernel operations", especially for operating systems running on constrained hardware and real time systems. While the 4.4BSD implementation got rid of the vfork implementation, causing vfork to have the same behavior as fork, it was later reinstated in the NetBSD operating system for performance reasons. Some embedded operating systems such as uClinux omit fork and only implement vfork, because they need to operate on devices where copy on write is impossible to implement due to lack of a memory management unit.

The Plan 9 operating system, created by the designers of Unix, includes fork but also a variant called "rfork" that permits fine grained sharing of resources between parent and child processes, including the address space (except for a stack segment, which is unique to each process), environment variables and the filesystem namespace; this makes it a unified interface for the creation of both processes and threads within them. Both FreeBSD and IRIX adopted the rfork system call from Plan 9, the latter renaming it "sproc".

clone is a system call in the Linux kernel that creates a child process that may share parts of its execution context with the parent. Like FreeBSD's rfork and IRIX's sproc, Linux's clone was inspired by Plan 9's rfork and can be used to implement threads (though application programmers will typically use a higher level interface such as pthreads, implemented on top of clone). The "separate stacks" feature from Plan 9 and IRIX has been omitted because (according to Linus Torvalds) it causes too much overhead.

In the original design of the VMS operating system (1977), a copy operation with subsequent mutation of the content of a few specific addresses for the new process as in forking was considered risky. Errors in the current process state may be copied to a child process. Here, the metaphor of process spawning is used: each component of the memory layout of the new process is newly constructed from scratch. The spawn metaphor was later adopted in Microsoft operating systems (1993). The POSIX compatibility component of VM/CMS (OpenExtensions) provides a very limited implementation of fork, in which the parent is suspended while the child executes, and the child and the parent share the same address space. This is essentially a vfork labelled as a fork. (This applies to the CMS guest operating system only; other VM guest operating systems, such as Linux, provide standard fork functionality.)