vfork

[Keith Packard]

In article <22500003 at ima.UUCP> johnl at ima.UUCP writes:
>
>/* Written  1:22 am  Jul  8, 1985 by thomas at utah-gr in ima:net.unix-wizards */
>> The problem is that the initial design of the Vax (750?) had a flaw that
>> made copy-on-write VERY difficult (impossible?) to do.  So, the vfork
>> kludge was the only workable solution to avoid copying an entire process
>
>No it wasn't -- vfork really has to be chalked up to laziness.  It would
>have been entirely workable to do copy-on-touch in the stack segment (which
>was where the copy-on-write pages didn't work.)  Considering how little
>stack data is read but not written, the performance would have been about
>the same.
>
>On machines like the PDP-11, vfork makes more sense since the segments
>are too big to do practical copy-on-anything.
>
>John Levine, ima!johnl

No, it's not because the segments are too large.  It's because you
must have contiguous physical addressing on the pdp, otherwise
swapping becomes a nightmare (very important on pdp's remember) and
physical i/o becomes impossible (only the cpu goes through the
virtual memory map, not the i/o devices).  many portions of
the kernel depend on contiguous physical addresses of unix
processes; true copy-on-touch demands *real* virtual memory.

keith packard
speaker-to-pdp
...!tektronix!reed!motel6!keith
...!tektronix!azure!keithp