This is an interesting publication from Microsoft that talks about how
fork system call was something that should not exit in the era of modern operating systems.
Some highlights from the paper:
forksystem call was developed in old times where memory access was faster than instruction execution, so copying the addresses space of parent would have been faster (also, considering that memory and programs were relatively very small in those days).
forkwas simple in old days (the reason for it's popularity), but that is no longer the case. There are tons of corner cases listed in the POSIX API.
forkis slow and insecure today becuase a programmer has to take care of closing open file descrpiptors and switching namespaces when creating new processes.
- Becuase of the way
forkis implemented in modern systems, where a large part of the memory is de-deuplicated and only copied when written to (CoW mechanism), systems tend to overcommit a lot more. There is no good way to estimate if a process will ever write to those pages so it tends to be efficient in most cases but when proceses do want to write to those pages, there would be a burst in the usage which could fail depending on how much memory the system gave away without thinking about it.
forkis not compatible with single address space, so operating systems designs which consider running applications in a single address space tend to fail because they can't implement
forkand the widespread use of
forkmeans they won't be able to run many applications.
forkimpedes innovative research in operating systems and security era because of the assumption that you have to duplicate the address space for a child process. There are numerous papers trying to run operating systems inside a SGX Enclave for security reasons, but can't run multiple processes inside the same enclave.
There is lot more content in the paper and I urge you to read it. It is a relatively small 6 page paper.