A fork() in the Road.

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:

  • fork system 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).
  • fork was 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.
  • fork is 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 fork is 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.
  • fork is 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 fork and the widespread use of fork ┬ámeans they won't be able to run many applications.
  • fork impedes 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.