qfork() (again)

[Masataka Ohta]

Submitted-by: mohta at necom830.cc.titech.ac.jp (Masataka Ohta)

In article <17527 at cs.utexas.edu> domo at tsa.co.uk writes:

>The problem -- one problem -- is in coming up with a ``portable''
>definition of ``data space''. 

These are 'problems' (actually, not a problem) of C, not UNIX.

There is no problem about data space. C has clear and portable notion
of what is data space: register and memory. That's all.

It has very little to do with UNIX nor vfork().

>On what we currently assume to be
>``vanilla flavour'' architectures such as that of the 68000 which you
>cite, it's fairly obvious.  But on others, it's not.  What about
>registers?  Are they data space?  No?  Even on architectures with
>register windows which may or may not map onto main memory addresses?
>Bear in mind that such exotica are not so exotic any more: RISCs use
>them widely.

Clearly, on exotic architectures, a C (not UNIX) pointer may point
to a register. It may be an exotic feature of C. But, it never is a
problem of C nor UNIX nor vfork().

>It seems that any definition which is safe on all architectures is
>liable to constrain what one may do between [qv]fork() and exec() so
>greatly

No.

First, list every operations which is safe between fork() and exec()
*and* between BSD vfork() and exec().

Then, those are the safe operations of POSIX vfork() on *all* architectures.

>that it turns out to be better to define a combined spwan()
>function.

Most (perhaps, more than 90%) of cases where fork/exec is necessary
is covered by system(). spawn() is not necessary.

Rest are special cases, where combined spawn() can help very little
and separate [v]fork() and exec() is really necessary.

Is it a role of POSIX to define unnecessary and totaly alien functions
and badly modify UNIX?

Don't try to reinvent wheels.

					Masataka Ohta

Volume-Number: Volume 22, Number 100