[Richard Tobin]
| For unix, the problem is that there is so much that you can do between
| the fork() and exec() - shuffling file descriptors, changing directory,
| (un)ignoring signals etc. Do you build all these in as arguments to
| spawn()?
[Paul Wilson]
| Possibly, but the main thing is to identify the basic functionality and
| identify which things are worth adding via extra arguments or whatever.
operating systems that provide `spawn', usually have several system calls
that take the process to which they apply as an argument.
under TOPS-20 (V5 as of 1982-04), the CFORK (create fork) system call
allowed the calling process to create a new process with indirect pointers
in the process map (copy-on-write was available as one of several options)
or have an empty map (the creating process could add pages with various
system calls in either case), inherit the system capabilities (privileges)
of the creating process or have none, inherit the accumulators (registers)
of the creating process or have them zeroed out, and could receive a new
program counter and run from there or not start running until the creating
process wanted it to. once created, the creating process could manipulate
the inferior process with precise control.
note that the semantics of Unix `fork' is a strict subset of TOPS-20's
`CFORK'. TOPS-20 also differentiated between `job' and `fork', which
allowed a job to be a much heavier system object than a fork, unlike Unix,
which has had to let the fork gain weight to fight badly in both classes,
leading to such historical tragedies as "lightweight processes".
this was running in the spring of 1982 on computers whose capacities than
we now take for granted. we still haven't learned from history. ignorance
may be bliss for whoever suffers from it, but for those who know what was
and see what people keep reinventing (I'm not talking about scsh, but of
the many Unix vendors and their highly commercialized System V Release 4 in
particular), their ignorance is excrutiatingly painful to behold.
I would love to see a programming environment that learned from history,
instead of being hell bent on repeating the bad ideas and none of the good.
#\Erik
|