home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso / std_unix / v22 / 100 < prev    next >
Internet Message Format  |  1991-03-07  |  3KB
  1. From jsq@cs.utexas.edu  Sun Feb  3 12:57:18 1991
  2. Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP 
  3.     id AA09305; Sun, 3 Feb 91 12:57:18 -0500
  4. Posted-Date: 3 Feb 91 12:43:12 GMT
  5. Received: by cs.utexas.edu (5.64/1.93) 
  6. From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
  7. Newsgroups: comp.std.unix
  8. Subject: Re: qfork() (again)
  9. Message-Id: <17598@cs.utexas.edu>
  10. References: <16992@cs.utexas.edu> <17010@cs.utexas.edu> <17402@cs.utexas.edu> <17527@cs.utexas.edu>
  11. Sender: jsq@cs.utexas.edu
  12. Organization: Tokyo Institute of Technology
  13. X-Submissions: std-unix@uunet.uu.net
  14. Date: 3 Feb 91 12:43:12 GMT
  15. Reply-To: std-unix@uunet.UU.NET
  16. To: std-unix@uunet.UU.NET
  17.  
  18. Submitted-by: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
  19.  
  20. In article <17527@cs.utexas.edu> domo@tsa.co.uk writes:
  21.  
  22. >The problem -- one problem -- is in coming up with a ``portable''
  23. >definition of ``data space''. 
  24.  
  25. These are 'problems' (actually, not a problem) of C, not UNIX.
  26.  
  27. There is no problem about data space. C has clear and portable notion
  28. of what is data space: register and memory. That's all.
  29.  
  30. It has very little to do with UNIX nor vfork().
  31.  
  32. >On what we currently assume to be
  33. >``vanilla flavour'' architectures such as that of the 68000 which you
  34. >cite, it's fairly obvious.  But on others, it's not.  What about
  35. >registers?  Are they data space?  No?  Even on architectures with
  36. >register windows which may or may not map onto main memory addresses?
  37. >Bear in mind that such exotica are not so exotic any more: RISCs use
  38. >them widely.
  39.  
  40. Clearly, on exotic architectures, a C (not UNIX) pointer may point
  41. to a register. It may be an exotic feature of C. But, it never is a
  42. problem of C nor UNIX nor vfork().
  43.  
  44. >It seems that any definition which is safe on all architectures is
  45. >liable to constrain what one may do between [qv]fork() and exec() so
  46. >greatly
  47.  
  48. No.
  49.  
  50. First, list every operations which is safe between fork() and exec()
  51. *and* between BSD vfork() and exec().
  52.  
  53. Then, those are the safe operations of POSIX vfork() on *all* architectures.
  54.  
  55. >that it turns out to be better to define a combined spwan()
  56. >function.
  57.  
  58. Most (perhaps, more than 90%) of cases where fork/exec is necessary
  59. is covered by system(). spawn() is not necessary.
  60.  
  61. Rest are special cases, where combined spawn() can help very little
  62. and separate [v]fork() and exec() is really necessary.
  63.  
  64. Is it a role of POSIX to define unnecessary and totaly alien functions
  65. and badly modify UNIX?
  66.  
  67. Don't try to reinvent wheels.
  68.  
  69.                     Masataka Ohta
  70.  
  71. Volume-Number: Volume 22, Number 100
  72.  
  73.