I don't pay much attention to this stuff any more but I do recall being absolutely *astonished* how complex the re-binding of process to inherited I/O was in a lot of systems in the 1980s fork() and the various exec() flavours had this single compelling story for me: the stdin/stdout/stderr *and all other open I/O* was inherited across the process boundary. This alone made writing code significantly easier. I did briefly find myself in a world where it wasn't clear where an X.25 binding was (this was Yorkbox, and then the UCL-CS version of the same idea, and the per-ISODE OSI stack work) on an FD, but it wasn't immediately clear which. We wound up passing a binary-encoded text blob in the execve() info to "inform" the child what it was meant to look for in file descriptors, to (re)bind as the X.25 FD to work with. It felt really creepy to do this, but we simply couldn't find a way round it. Other systems "for your convenience" felt it was far, far kinder to either completely obscure the binding of I/O or even terminate it. Truly bizarre. Actual runtime cost to mechanise the COW state. and the other bits of kernel state, and instantiate the process, and fiddly bits were stuff I simply didn't think about much. it felt like some giant bcopy() call in the kernel did something in VM aware memory addressing to make a "copy" of something, which then ran, because it existed. As if you could clone a vertial slice of the layers of the onion and simply carry on, irrespective. But if somebody said VMS or the nascent Microsoft kernel was "better" I would (and probably still would) be skeptical. Hard to beat simple. On Thu, Apr 11, 2019 at 9:25 AM Bakul Shah <bakul(a)bitblocks.com> wrote:

On Apr 10, 2019, at 4:06 PM, Richard Salz <rich.salz(a)gmail.com> wrote: Quite correct in my experience. The posix_spawn() API isn’t a panacea but (especially with a few *_np extensions) it’s much saner for large real-world applications that run a ton of subprocesses. I work on a large IDE which invokes compilers and such, and it makes a huge difference. The biggest need for *_np extensions has been control over fd inheritance and chdir behavior. Otherwise a subprocess can wind up inheriting random or no fds from a multithreaded process (thanks to the race between setting up and finishing the call) and you need to use pthread_{chdir,fchdir}() or openat() to set the working directory in which the subprocess is launched. -- Chris

I think the problem with fork() is that it's elegance invites people to use it outside its sweet spot. I always thought (perhaps wrongly) that fork() didn't have to copy all the memory, just the stack and user areas, and that VM page table entries were cloned to share the code segment. fork() is beautiful for what it is and what it does. Being able to create a mirror image of the current process, and to be able to share all the I/O and signal states is cool, if that's what you want. I think the author of the micro$oft article is complaining that fork() shares too much, and therefore to use it is a security risk. If you don't want to share all that stuff, maybe you shouldn't be using fork(), or, you should fork() early, sharing EXACTLY what you want to share and nothing more, and then differentiate with exec(). C is elegant. C can also be dangerous if you don't use it wisely. I think the author should take a lesson from "The Kings Toaster". http://www.ee.ryerson.ca:8080/~elf/hack/ktoast.html Cheers, Jim From: "Richard Salz" <rich.salz(a)gmail.com> To: tuhs(a)tuhs.org Sent: Wednesday, April 10, 2019 7:06:23 PM Subject: [TUHS] "Fork considered harmful" Any view on this? https://www.microsoft.com/en-us/research/publication/a-fork-in-the-road/