3 ms·
> What would we do about all of the processes that fork but don't ever exec? I speculate it isn't common, or at least it isn't required for ordinary desktop ap
by orra 4y ago
> What would we do about all of the processes that fork but don't ever exec?
I speculate it isn't common, or at least it isn't required for ordinary desktop apps. Windows survives without fork().
> And isn't posix_spawn implemented in terms of vfork, which a lot of people like even less?
That sounds like a glibc implementation detail, not something required by the standard. I'm not an expert however. Simply, again I come back to: Windows can spawn processes without using it as an excuse to overcommit.
- josephcsible 4y agoWindows is a terrible OS, especially for servers, so pointing out that it doesn't have something isn't really a great argument for that thing not being very important.
- orra 4y agoWindows is proprietary and until recently, not very scriptable. None of that is relevant. We're talking about desktop users having their session killed.
- takluyver 4y ago> I speculate [fork] isn't common, or at least it isn't required for ordinary desktop apps. From a science perspective, the ability to fork is really convenient for parallel processing. Load some data and then fork a pool of worker processes, and they can all read almost free copies of that data. This is much easier than setting up shared memory. It's a bigger deal on an HPC machine with 128 cores than a laptop with 8 cores, but even on a laptop it's a significant point in favour of Linux. Getting rid of it in Linux would also be going against Linus' rule that the kernel never breaks userspace.