Re:Non-uniform memory access meets the OOM killer
by ams6110 on Saturday March 31, 2018 @06:12PM
(#16725432)
> if a big one wants to spawn children
Should this be considered poor behavior or design?
It's been quite a while since I wrote explicit fork/ exec code, but wouldn't a better approach be to have a small master process that spawns off the necessary children and then either links them up or mediates communication?
I mean, on a unix-like system, init is ultimately the spawner of everything else and it's not a particularly large process.
Re:Non-uniform memory access meets the OOM killer
by wilun on Saturday March 31, 2018 @08:10PM
(#16725890)
Yes on Unix it can be interesting, if needing fork/exec to spawn children, to pre spawn an helper child process that will do just that. But that would just be because the fork/exec model is insane: with a posix_spawn (or CreateProcess) centric approach, you don't have to add that extra layer, and you have very few drawbacks. Also, that will not help you when trying to use libraries that attempt to spawn on their own.
As for init being small, I leave you the responsibility of your words, now that we live in a systemd world :p
Sadly there is no good (& simple) solution under most Unixes (that's a problem that only affects long running and big processes, but those are often the main applications of some embedded systems). I'm not really found of vfork now that we use threads more often (well, at least on Linux it seems other threads are not suspended, but it seems that this is not a Posix guarantee)... posix_spawn could be a solution if implemented with some dedicated kernel support (or always implemented through well-behaved existing ones).