Because it comes with a lot of overhead and, unless for some reason you really need every of those processes to have their own address space, set of privileges, file descriptors, etc., there's no point in wasting resources repeatedly setting those up only to tear them down milliseconds later. Running the same workloads in an nginx-style process pool usually works better.
Sure, but not many times a second
Every build system ever says hello.
Why not?
Because it comes with a lot of overhead and, unless for some reason you really need every of those processes to have their own address space, set of privileges, file descriptors, etc., there's no point in wasting resources repeatedly setting those up only to tear them down milliseconds later. Running the same workloads in an nginx-style process pool usually works better.
1 reply →
Spawning processes should not be on the hot path of any program.
Why? That's a very useful processing primitive.
It’s a hack with many disadvantages. Sometimes a hack is the right answer, but the kernel should it add a primitive for it.
8 replies →
It ends up on the hot path of programs that use process isolation aggressively
Sure, and there a primary thing you want is a whole new environment/context for the child (new environment, fds, memory, cgroups, namespaces, etc).