home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.22 / text0058.txt < prev    next >
Encoding:
Text File  |  1991-03-06  |  3.1 KB  |  61 lines
  1. Submitted-by: domo@tsa.co.uk (Dominic Dunlop)
  2.  
  3. In article <16483@cs.utexas.edu> lewine@dg.uucp (Donald Lewine) writes:
  4.  
  5. >     I think I would vote "NO" on qfork().  I think that there are 
  6. >     two better solutions:
  7. >     (1) Just use fork() and require the implementation to do it
  8. >         in an efficient manner.
  9.  
  10. Well, I know that we POSIX folks want to rule the world, but just how
  11. ugly a world will we put up with in order that we can rule it?  qfork()
  12. (and vfork()) special-case a particular usage of the process creation
  13. mechanism in order to give implementors an easier time of it.  By now we
  14. know that in a ``from to ground up'' virtual memory implementation of
  15. UNI*X with a half-way useful memory management hardware copy on write and
  16. similar finessing can make the general-case fork() call as efficient as
  17. any special-case variant, and, unlike the variants, is free from any
  18. threat that sixteen ton weights will be dropped on any programmer who
  19. steps out of line.
  20.  
  21. That said, POSIX has nothing to say about the efficiency of any
  22. particular implementation: that's a quality issue, not a conformance
  23. issue.  One hopes that in the kind of free market that standards are
  24. supposed to encourage, better quality will win out over poorer quality,
  25. other things being equal.  So, yes, I'm in favour of keeping just
  26. fork(), and letting implementors worry about how slick they need to make
  27. it.  After all, there's few implementors in this world than applications
  28. programmers, so it seems to make sense to localize the pain involved to
  29. the smaller group.  Sorry about that.  I am aware that the efficient
  30. implementation of fork() is a real headache on some architectures, and
  31. particularly in hosted POSIX, but, well, so's cooking up fake inodes
  32. (or parts thereof).  Happily, I hear nobody suggesting that we define
  33. unsafe versions of stat() to get around that problem.  Just how far
  34. should we bend over backwards to accommodate history?  Remember that
  35. every extra function we define has to be maintained on all
  36. implementations for ever more (more or less), and that every extra
  37. function is something else that programmers have to learn about.
  38.  
  39. >     (2) Add some new functions (fexec() ?) which do the fork() and
  40. >         exec() in one call.  I know that this is not existing practice
  41. >         but neither was sigemptyset() or tcgetispeed().  This may be
  42. >         another case where it is better to define a new interface than
  43. >         to try to describe the existing practice.  [[Also, qfork() is
  44. >         not quite vfork() so it can be shot down on the same basis.]]
  45.  
  46. I don't like this much either, but it might be an acceptable compromise
  47. if the effect of the new functions was defined in the standard in terms
  48. of fork() and exec() family functions.  This would make it easy to bring
  49. existing implementations with an efficient fork() into line.  Please
  50. let's resist the temptation to add new functionality to exec (for
  51. example) on the way past.
  52.  
  53. By the way, what line (if any) are the .5 (Ada) folks taking on this
  54. issue?  How does all this square (if at all) with Ada's concept of a
  55. task?
  56. -- 
  57. Dominic Dunlop
  58.  
  59. Volume-Number: Volume 22, Number 60
  60.  
  61.