> > > That's why many OSes have a "spawn" primitive that combines fork-and-exec.
> >
> > the problem with spawn is it requires a mechanism to replace that little
> > block of code between the fork and exec. that code is hardly ever the
> > same so spawn keeps growing arguments.
>
> Yes, on the other hand I bet a spawn interface could be devised that
> is sufficiently programmable. (May require some extra dup()s etc. to
> really handle all the common usage patterns.)
What could accomplish this are hooks into the process-creation bits of
the kernel. I've lost the links to this, but some toy OS accomplished
process creation with the equivalent of 'cp /bin/ls /proc/clone'.
This isn't useful on its own, but it could be an interesting exercise
to construct a process outside the kernel and kick-start it somehow.
The one somewhat useful application of this idea would be to mitigate
the bug documented in notify(2):
Since exec(2) discards the notification handler, there
is a window of vulnerability to notes in a new process.
In a hand-rolled spawn(), one could conceivably install a notification
handler before the process starts executing or accepting notes.
Possibly some form of dynld() could be built on this too.
I can't imagine that either of these uses are nearly compelling enough
to open this can of worms.... Has anyone truly felt confined by Plan
9's fork+exec model?
--Joel
