home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v3 / text0028.txt < prev    next >
Encoding:
Text File  |  1987-06-30  |  2.0 KB  |  41 lines
  1. [ This is from a committee member who is more knowledgeable than I.
  2. The usual disclaimers about not necessarily representing the official
  3. position of IEEE, P1003, etc. apply.  -mod ]
  4.  
  5. From: athena!steved%tektronix.csnet@CSNET-RELAY.ARPA
  6. Date: Tuesday, 19 Nov 85 10:27:06 PST
  7.  
  8. -----
  9. John, 
  10.  
  11. In response to Dan Franklin's letter about changes in the standard concerning
  12. the misleading (and sometimes contradictory) wording in the limits section.
  13. In preparing draft 6, this section was cleaned up by the technical reviewers.
  14.  
  15. The body of the paragraph now says that the magnitude of the defined value 
  16. must be greater than or equal to the magnitude of the value specified and
  17. they must be of the same sign.  Also the column is simply labeled "Value".
  18.  
  19. This should clear up the ambiguity of the section.
  20.  
  21. On the question of these values being obtainable dynamically,  The intention
  22. of this section is to present minimum magnitudes that the implementer can
  23. be certain of having for a given implementation.  I.E. if the designer
  24. makes sure that his application fits (so to speak) within these limits
  25. it will work on any system.  I feel that the question of querying the values
  26. at run time is really a different topic.  There really needs to be the two
  27. classes of limits available. The limits file is not intended to represent
  28. necessarily the current limit.  For example, PROC_MAX tells an application
  29. programmer that he knows that there can be n processes existing simultaneously.
  30. However, the o.s. implementer may have some dynamic allocation scheme where
  31. the actual limit varies with say system load.  The goal of the standard is to
  32. allow that kind of implementation.
  33.  
  34. The working committee will certainly accept and consider proposals for a 
  35. routine that would provide the more esoteric program the ability to dynamically
  36. determine what "current" limits are.  Clearly the case of the shell, wanting
  37. to close all unused file descriptors is a good case for the routine.
  38.  
  39. Volume-Number: Volume 3, Number 30
  40.  
  41.