| 5 | | In traditional UN*X, new processes are created by duplicating the resources of the current process via a call to `fork()`. Forking a process will, among other things, clone the current thread of that process. After `fork()`, both threads typically test whether they are the parent or the child instance. Very often, the child thread makes a call to `exec()` to load a new program. Calling `exec()` replaces the contents of the address space of the entire process with the new content of the loaded program. As can be seen, especially without heavy optimizations such as copy-on-write allocation of memory pages and non-duplicating variants of `fork()` such as |
| | 5 | In traditional UN*X, new processes are created by duplicating the resources of the current process via a call to `fork()`. Forking a process will, among other things, clone the current thread of that process. After `fork()`, both threads typically test whether they are the parent or the child instance. Very often, the child thread makes a call to `exec()` to load a new program. Calling `exec()` replaces the contents of the address space of the entire process with the new content of the loaded program. As can be seen, especially without heavy optimizations such as copy-on-write allocation of memory pages and non-duplicating variants of `fork()` such as `vfork()`, the procedure of spawning a new program is quite wasteful. This is the reason why UN*X standards introduced `posix_spawn()` which should be the way forward, but fork()/exec() will probably remain for backward compatibility (forever?) |
