Comment by gumby
4 years ago
The fact that 99.9+ invocations of fork() are immediately followed by exec() shows that the abstraction is a mistake.
Unix would have been better if execution thread and address space had been separate abstractions.
4 years ago
The fact that 99.9+ invocations of fork() are immediately followed by exec() shows that the abstraction is a mistake.
Unix would have been better if execution thread and address space had been separate abstractions.
Are subshells and multiprocess servers really less than 0.1% of forks on most UNIX and Linux systems? And I'm sure there's more things than them that fork without execing; they're just the two that came to mind immediately.
Dumping memory state to disk (e.g. how Redis works) is another example of fork without exec.
Additionally, it can also be used in languages that don't have good support for threading (e.g. PHP) to implement parallel processing with shared memory.
However, I'd say that Redis use case is probably the only legit use case (today) of fork without execing, where benefits are huge, and there is no good replacement.
I think you mean execution process, not thread.
That said, processes should not share virtual address spaces by default. Sharing memory between processes should be an explicit choice.
(Or should 99.9% of calls to spawn() be followed by new_address_space()? )
The researchers can write their own single address space os if they are so inclined.