Re: [TUHS] "Fork considered harmful"

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: