OPEN_MAX and other constants - are they desireable?

[Moderator, John Quarterman]

Date: 06 Oct 85 18:36:07 +1000 (Sun)
>From: Robert Elz <munnari!kre at seismo.CSS.GOV>

Section 2.7 of P1003 draft 4 [ Section 2.8 of Draft 5 -jsq ]
requires that implementations must define values of certain
constants in <limits.h>.

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 <limits.h> 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 <limits.h>
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).

<limits.h> 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 at seismo.css.gov

Volume-Number: Volume 3, Number 10