Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site ut-sally.UUCP Path: utzoo!watmath!clyde!cbosgd!ucbvax!ucdavis!lll-crg!mordor!ut-sally!std-unix From: std-unix@ut-sally.UUCP (Moderator, John Quarterman) Newsgroups: mod.std.unix Subject: OPEN_MAX and other constants - are they desireable? Message-ID: <3430@ut-sally.UUCP> Date: Fri, 8-Nov-85 21:40:27 EST Article-I.D.: ut-sally.3430 Posted: Fri Nov 8 21:40:27 1985 Date-Received: Sun, 10-Nov-85 10:04:04 EST Organization: IEEE/P1003 Portable Operating System Environment Committee Lines: 100 Approved: jsq@ut-sally.UUCP Date: 06 Oct 85 18:36:07 +1000 (Sun) >From: Robert ElzSection 2.7 of P1003 draft 4 [ Section 2.8 of Draft 5 -jsq ] requires that implementations must define values of certain constants in . One of the required constants is OPEN_MAX, the maximum number of files that one process can have open at any given time. The problem I see with this limit is quite different than that I perceive with CHILD_MAX (mentioned in a previous mail item), though the problems there could apply here as well, a per process limit is just a special case of a per user limit. Which is to say, that there is no guarantee that this limit will be a constant across users. With OPEN_MAX though, there is another problem. Defining this as a constant will lead application programs to reference it. (If these constants are not intended to be referenced, then that should be clearly stated, in which case I will wonder what the intention of them is). [ I think they are intended to be referenced by C code (in most cases). -Gwyn ] The problem here, is that this makes binary compatability of application processes across system generations hard to achieve. That is, generating a new binary kernel image may require recompiling large numbers of application programs, without any particularly good cause. [ Agreed, but binary compatibility is not a goal of this standard. -Kretsch ] [ Applications intended to be ported in binary form would have to restrict themselves to the minimum possible sizes for those things that can vary from system to system. This would entail a special on the development system. Is this really a problem? (Non-rhetorical question.) -Gwyn ] This applies to many (if not almost all) of the constants defined in section 2.7 [ 2.8 of D5 -jsq ], I have singled OPEN_MAX out for attention, as it is one that I can see some implementations changing regularly. Occasionally an application appears that really needs a large value for OPEN_MAX to be effecient. If that application is important enough, a site may want to increase the limit. As long as this means no more than a system generation, and reboot, it is a practicable task, however if all, or most of the user-mode binaries need to be rebuilt, it becomes close to impossible. [ Seems to me only those critical binaries (/etc/init?) that wanted a huge OPEN_MAX would need to be rebuilt. -Gwyn ] I suggest deleting all of the constants, and instead specifying a library routine, which when handed a name defined in will return the associated constant. [ A la getenv() - sounds reasonable to me. X3J11 only deals with a single process mmodule so they haven't considered different values of these limits for different users/processes. Maybe P1003 should! -Kretsch ] It may be that for various reasons a few of the limits really deserve to remain constants (the ones that specify characteristics of the hardware may be candisates), but most of these "constants" are really no more than transitory constants, and should not be wired in anywhere. A simplistic implementation of the function would simply index an array by its argument, and return the number found. This results in building the constants into the binaries just as the current scheme - but it also discourages their use in places where constants are "required" by the C standards, making any application that does this non-portable to an implementation where these "constants" are true variables. Other implementations may involve reading a file, or performing system calls. The mechanism is not important. [ Unfortunately, OPEN_MAX is one very likely candidate for use as a C integer constant (such as defining the size of an array of file status flags). has been the subject of much debate, for the reasons you give and for others. I think we really want to have minimum guaranteed limits on things, and really want to have C constants. Attempting to change to a different mechanism at this point would probably delay balloting on the "trial use" standard. This seems like a good topic to bring up when critiquing the trial use standard, so that an acceptable solution could be built into the final use standard. Perhaps feedback on this should be solicited in Appendix A. -Gwyn ] Robert Elz seismo!munnari!kre kre%munnari.oz@seismo.css.gov Volume-Number: Volume 3, Number 10