home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v3 / text0006.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  2.6 KB
  1. Date: 06 Oct 85 18:53:05 +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 CHILD_MAX, the maximum number
  9. of offspring per userid.
  10.  
  11. This definition is a little to vague to be useable (it most likely
  12. intends to specify the maximum number of processes per userid, it may
  13. be debated whether the first process for a userid is an "offspring",
  14. it is also unlear whether this applies to "offspring" from some
  15. particular process - perhaps the maximum number of processes a user
  16. is permitted to run per login session?)
  17.  
  18. This can easily be fixed, but I have a more serious complaint:
  19.  
  20. Specifying per-userid limits as constants (that is, requiring
  21. an implementation to specify such a constant, and constraining
  22. it to a minimum value of that constant) does not seem to be
  23. an intelligent thing to do.
  24.  
  25. Ideally, per-userid limits are exactly that, set individually
  26. for individual users.  In an enviroment like this (again, mine)
  27. am I to set CHILD_MAX to the maximum number of processes that
  28. any user may may have running (which would be the same as PROC_MAX,
  29. as userid == 0 may run this many, and as such would be a meaningless
  30. value), or should I set it to the mininum value that any user
  31. will ever have for the maximum number of process permitted to be
  32. running (for some users, that will be 1 [aside: I can give
  33. entirely reasonable justifications for this limit - for some
  34. userids who do not represent humans], again making the constant useless.
  35. I could set it to an arbitrary approximate value - one that
  36. applies to many, or most, users, but that hardly seems satisfactory
  37. either.
  38.  
  39. So, I recommend doing away with this constant from <limits.h>,
  40. which is not to say that implementations may not impose such
  41. a limit, merely that attempting to specify the value of the
  42. limit as a system wide constant is not reasonable.
  43.  
  44. [ I think the justification for CHILD_MAX was that some
  45. implementations do have such a limit (for UIDs other than 0),
  46. and they wanted to guarantee a "minimum limit" of 4 offspring.
  47. Your argument against CHILD_MAX is a good one, though.
  48. For more general objections to <limits.h>, see farther on..
  49. -Gwyn ]
  50.  
  51. Robert Elz        seismo!munnari!kre    kre%munnari.oz@seismo.css.gov
  52.  
  53. [ Note that the X3J11 draft has the same problems as the P1003 draft,
  54. since they have many of the same constants defined, and where that is so,
  55. they have the same definitions (I think P1003 got them from X3J11).
  56. X3J11 has a copy of the original mail items through Don Kretsch.  -jsq ]
  57.  
  58. Volume-Number: Volume 3, Number 7
  59.  
  60.