home *** CD-ROM | disk | FTP | other *** search
- Submitted-by: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
-
- In article <17527@cs.utexas.edu> domo@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
-
-