home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v3 / text0007.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  3.0 KB
  1. Date: 06 Oct 85 18:53:44 +1000 (Sun)
  2. >From: Robert Elz <munnari!kre@seismo.CSS.GOV>
  3.  
  4. In section 2.3 [ of Draft 4; Section 2.4 of Draft 5 -jsq ],
  5. EAGAIN is defined as "Resource temporarily unavailable".
  6. The third sentence of its description states...
  7.  
  8.     This is a temporary condition and later calls to the
  9.     same routine may complete normally.
  10.  
  11. It is not abundently clear whether this sentence qualifies only
  12. the preceding one (about read/write with O_NDELAY) or both of
  13. the earlier sentences (the first refers to fork).
  14.  
  15. [ This has been fixed in Draft 5 by moving the sentence to the
  16. beginning of the paragraph. -Gwyn ]
  17.  
  18. In section 3.1, and also in the the first sentence of the description
  19. referred to above, fork() is stated to return EAGAIN if either
  20. the system process table is full (PROC_MAX would be exceeded), or
  21. if the limit on the number of processes runnable by a single userid
  22. (CHILD_MAX) would be exceeded.
  23.  
  24. I submit that these conditions represent two distinct errors, which
  25. should not be lumped together - in most cases proper handling of a
  26. process table full is to wait a while, and try again (my exact
  27. interpretation of "Resource temporarily unavailable").  However,
  28. in most cases, this is a fruitless exercise if the user has exceeded
  29. the number of processes he is permitted - only killing one of the
  30. user's running processes will usually have much effect (it is
  31. possible that there are background processes, which may soon terminate,
  32. but this would seem to be the exception, rather than the rule).
  33. The process to kill when a fork fails because of the user having
  34. too many running processes is logically the parent process, the
  35. one attempting to fork().
  36.  
  37. [ Processes can terminate for other reasons, such as completion
  38. of their assigned tasks, in which case trying fork() again may
  39. eventually succeed.  The wording of the Draft ("may") seems to
  40. be such that the programmer is never guaranteed that the
  41. resource in question will ever become available. -Gwyn ]
  42.  
  43. [ For those of you who are not aware of it, the words "shall,"
  44. "should" and "may" are magic words with very specific meanings
  45. which are mandated by IEEE for standards of this kind.  See
  46. Section 1.2 of Draft 5 for the precise definitions.  This
  47. particular point about fork has been discussed in the committee
  48. before, and the word "may" was chosen carefully.  -jsq ]
  49.  
  50. So, I would suggest adding a new error code, I call it EPROCLIM
  51. (4.2 sites should find it already defined in their <errno.h> files!)
  52. and having fork() return this if the error is that the user's
  53. process limit is reached.
  54.  
  55. I know that this is incompatible with many (all, except mine)
  56. kernel implementations, however, I think that can easily be
  57. rectified by making it clear that EPROCLIM and EAGAIN may
  58. be the same value.
  59.  
  60. I think this is a suitable compromise that enables sensible
  61. forward growth, while not damaging backwards portability.
  62.  
  63. [ That is a sensible suggestion, but since it is not the way
  64. current systems work it may be hard to get a consensus on it. -Gwyn ]
  65.  
  66. Robert Elz        seismo!munnari!kre    kre%munnari.oz@seismo.css.gov
  67.  
  68. Volume-Number: Volume 3, Number 8
  69.  
  70.