[Info-vax] CRTL and RMS vs SSIO

[Lawrence D’Oliveiro]

On Saturday, October 9, 2021 at 4:37:26 AM UTC+13, Stephen Hoffman wrote:
> Having looked at this back in the VAX era, the slow process creations 
> our apps were incurring were arising from inefficiencies within the DCL 
> spawn-related processing, and not from within the OpenVMS process 
> creation overhead. 
> 
> Once that was identified and the obvious work-around implemented, 
> spawns were pretty speedy even VAX-era. 
> 
> To Simon's comment, how DCL gets mapped into process address space is 
> just ugly, too. And hard to debug.

But the whole reason why DCL maps into a process in this way, so that user-mode code can be repeatedly loaded, run and then wiped from the same process, was precisely to avoid multiple process creations. Now you are saying that the DCL mechanism itself contributes to the overhead of process creations!

But “spawn” is still not the same as “fork”. Sure, in *nix, the “fork” followed by “exec” idiom is common, but lots of forks are done without an accompanying exec (I’ve done a few myself). In the early days of Unix, the “vfork” hack was invented to speed things up in the fork+exec case, but this was later discovered to be unnecessary: not (so much) because hardware had become faster, but it was recognized that the bottleneck of giving the child process its own copy of non-shared writable memory could be avoided/postponed by just copying the relevant page table entries and setting a “copy-on-write” flag on them.

What do you know, vfork(2) was actually specified in POSIX, and Linux still supports it <https://manpages.debian.org/bullseye/manpages-dev/vfork.2.en.html>.