3 ms·
Spawning processes should not be on the hot path of any program.
by aerzen 4mo ago
Spawning processes should not be on the hot path of any program.
- 1718627440 4mo agoWhy? That's a very useful processing primitive.
- lokar 4mo agoIt’s a hack with many disadvantages. Sometimes a hack is the right answer, but the kernel should it add a primitive for it.
- MBCook 4mo agoShould bash link in every program the user might want? Load them up as dynamic libraries?
- m132 4mo agoNode, Python, PowerShell, and the rest do (almost) just that. launchd and systemd famously strived to remove as much shell from the start up process as possible because it was harming boot times and introducing unpredictability.
- sanderjd 4mo agoI don't know Node or PowerShell very well, but I'm not sure what you mean by this with respect to Python.
- m132 4mo agoCPython doesn't usually create subprocesses unless specifically asked to, it loads Python modules and native extensions into its process. The former is similar (you're still extending an existing process with new code, just interpreted), the latter is literally dlopen(), so loading dynamic libraries. A lot of other Python implementations don't have the ability to spin up new processes at all too.
- sanderjd 4mo agoI still don't really get this point. It's just two different things, spawning processes and running libraries. Seems like you're comparing apples and oranges to me.
- lokar 4mo agoBash as an interactive tool is very different. It is used to run an almost arbitrary number of things, and a pretty low rate. Bash as a programming language is just a bad idea.
- sanderjd 4mo agoAren't we discussing just such a primitive?
- lokar 4mo agooh, sorry, typo s/it/not/
- pizlonator 4mo agoIt ends up on the hot path of programs that use process isolation aggressively
- lokar 4mo agoSure, and there a primary thing you want is a whole new environment/context for the child (new environment, fds, memory, cgroups, namespaces, etc).