home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v3 / text0009.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  4.3 KB
  1. Date: 06 Oct 85 18:36:07 +1000 (Sun)
  2. >From: Robert Elz <munnari!kre@seismo.CSS.GOV>
  3.  
  4. Section 2.7 of P1003 draft 4 [ Section 2.8 of Draft 5 -jsq ]
  5. requires that implementations must define values of certain
  6. constants in <limits.h>.
  7.  
  8. One of the required constants is OPEN_MAX, the maximum number
  9. of files that one process can have open at any given time.
  10.  
  11. The problem I see with this limit is quite different than
  12. that I perceive with CHILD_MAX (mentioned in a previous mail
  13. item), though the problems there could apply here as well,
  14. a per process limit is just a special case of a per user limit.
  15. Which is to say, that there is no guarantee that this limit
  16. will be a constant across users.
  17.  
  18. With OPEN_MAX though, there is another problem.  Defining this
  19. as a constant will lead application programs to reference it.
  20. (If these constants are not intended to be referenced, then that
  21. should be clearly stated, in which case I will wonder what the
  22. intention of them is).
  23.  
  24. [ I think they are intended to be referenced by C code
  25. (in most cases).  -Gwyn ]
  26.  
  27. The problem here, is that this makes binary compatability of
  28. application processes across system generations hard to
  29. achieve.  That is, generating a new binary kernel image
  30. may require recompiling large numbers of application programs,
  31. without any particularly good cause.
  32.  
  33. [ Agreed, but binary compatibility is not a goal of this standard.
  34. -Kretsch ]
  35.  
  36. [ Applications intended to be ported in binary form would
  37. have to restrict themselves to the minimum possible sizes
  38. for those things that can vary from system to system.
  39. This would entail a special <limits.h> on the development
  40. system.  Is this really a problem?  (Non-rhetorical question.)
  41. -Gwyn ]
  42.  
  43. This applies to many (if not almost all) of the constants defined in
  44. section 2.7 [ 2.8 of D5 -jsq ], I have singled OPEN_MAX out for
  45. attention, as it is one that I can see some implementations changing
  46. regularly.  Occasionally an application appears that really needs a
  47. large value for OPEN_MAX to be effecient.  If that application is
  48. important enough, a site may want to increase the limit.  As long as
  49. this means no more than a system generation, and reboot, it is a
  50. practicable task, however if all, or most of the user-mode binaries
  51. need to be rebuilt, it becomes close to impossible.
  52.  
  53. [ Seems to me only those critical binaries (/etc/init?)
  54. that wanted a huge OPEN_MAX would need to be rebuilt.  -Gwyn ]
  55.  
  56. I suggest deleting all of the constants, and instead specifying
  57. a library routine, which when handed a name defined in <limits.h>
  58. will return the associated constant.
  59.  
  60. [ A la getenv() - sounds reasonable to me.  X3J11 only deals with
  61. a single process mmodule so they haven't considered different
  62. values of these limits for different users/processes.  Maybe
  63. P1003 should!  -Kretsch ]
  64.  
  65. It may be that for various reasons a few of the limits really
  66. deserve to remain constants (the ones that specify characteristics
  67. of the hardware may be candisates), but most of these "constants"
  68. are really no more than transitory constants, and should not
  69. be wired in anywhere.
  70.  
  71. A simplistic implementation of the function would simply
  72. index an array by its argument, and return the number found.
  73. This results in building the constants into the binaries
  74. just as the current scheme - but it also discourages their
  75. use in places where constants are "required" by the C standards,
  76. making any application that does this non-portable to an
  77. implementation where these "constants" are true variables.
  78.  
  79. Other implementations may involve reading a file, or
  80. performing system calls.  The mechanism is not important.
  81.  
  82. [ Unfortunately, OPEN_MAX is one very likely candidate for
  83. use as a C integer constant (such as defining the size of
  84. an array of file status flags).
  85.  
  86. <limits.h> has been the subject of much debate, for the reasons
  87. you give and for others.  I think we really want to have minimum
  88. guaranteed limits on things, and really want to have C constants.
  89.  
  90. Attempting to change to a different mechanism at this point
  91. would probably delay balloting on the "trial use" standard.
  92. This seems like a good topic to bring up when critiquing the
  93. trial use standard, so that an acceptable solution could be
  94. built into the final use standard.  Perhaps feedback on this
  95. should be solicited in Appendix A.
  96. -Gwyn ]
  97.  
  98. Robert Elz        seismo!munnari!kre    kre%munnari.oz@seismo.css.gov
  99.  
  100. Volume-Number: Volume 3, Number 10
  101.  
  102.