std-unix@ut-sally.UUCP (Moderator, John Quarterman) (11/09/85)
Date: 06 Oct 85 18:36:07 +1000 (Sun)
>From: Robert Elz <munnari!kre@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@seismo.css.gov
Volume-Number: Volume 3, Number 10std-unix@ut-sally.UUCP (Moderator, John Quarterman) (11/14/85)
Date: Wed, 13 Nov 85 17:02:39 est From: Kee Hinckley <harvard!wanginst!apollo!nazgul> In article <3430@ut-sally.UUCP> you write: > Date: 06 Oct 85 18:36:07 +1000 (Sun) > >From: Robert Elz <munnari!kre@seismo.CSS.GOV> ... > 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. > One problem with this is that a piece of code may want to #if off of particular constants. For instance, if I discover that the amount of memory I have is too small, and I don't have virtual memory then I might want to use temporary files. This could be all handled automatically by using #if's in the code if I could reference a constant, but it would not work out nearly as well if I had to make that kind of decision at runtime. I tend to agree with the other responses. The problems that are introduced by limits.h almost all relate to binary portability, and binary portability is not a concern for the standard. Kee Hinckley User Environment Apollo Computer ...decvax!wanginst!apollo!nazgul Volume-Number: Volume 3, Number 17
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (11/14/85)
Date: Sun, 10 Nov 85 16:26:26 PST From: mordor!lll-crg!sun!guy (Guy Harris) > [ Seems to me only those critical binaries (/etc/init?) > that wanted a huge OPEN_MAX would need to be rebuilt. -Gwyn ] Nope. What about programs like shells which want to close every single open file descriptor? If OPEN_MAX were a compile-time constant, these programs would have to be recompiled if you just bought Keg-O-Data's new DBMS which requires 100 open file descriptors and reconfigured your kernel to up the max-file-descriptors-per-process limit. > I suggest deleting all of the constants, and instead specifying > a library routine... Yes, and *please* call the one for OPEN_MAX "getdtablesize", so 4.2 programs won't have to change. Volume-Number: Volume 3, Number 13
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (11/15/85)
Date: Thu, 14 Nov 85 17:21:36 pst From: saber!msc@ihnp4.uucp (Mark Callow) > From: Kee Hinckley <harvard!wanginst!apollo!nazgul> > > In article <3430@ut-sally.UUCP> you write: > > Date: 06 Oct 85 18:36:07 +1000 (Sun) > > >From: Robert Elz <munnari!kre@seismo.CSS.GOV> > ... > > 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. > > > > One problem with this is that a piece of code may want to #if off of > particular constants. For instance, if I discover that the amount > of memory I have is too small, and I don't have virtual memory then > I might want to use temporary files. You can do this just as well with an if statement at runtime. Then if someone decides to add more memory to their machine they don't have to recompile their world to take advantage of it. > ...but it would not work out nearly as well if I had to > make that kind of decision at runtime. Why not? The penalty is a small increase in the size of the binary. limits.h and all similar kinds of wired-in constants are the pits. What happens in a network environment? Do your servers have one copy of the program for each client configuration? Of course not. What does a computer manufacturer do? Have a different software release for each system configuration? Of course not. You either end up in the least common denominator trap or you ignore limits.h and implement the library function suggested by kre. Volume-Number: Volume 3, Number 19
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (11/20/85)
Date: Mon, 18 Nov 85 11:13:43 pst From: seismo!gatech!hplabs!sdcrdcf!scgvaxd!felix!peregrine!mike (Mike Wexler) I have another argument against the desirability of these constants. It does not allow people to do implementations that don't have any limititations(other than availability of resources) It would be fairly easy to desing a system that would allow you to have an "unlimited" number of files, by allocating a new table when the current table gets full. Mike Wexler (trwrb|scgvaxd)!felix!peregrine!mike (714)855-3923 Volume-Number: Volume 3, Number 25
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (11/20/85)
From: shell!graffiti!peter (Peter da Silva) Date: Mon, 18 Nov 85 08:01:43 cst > > ...but it would not work out nearly as well if I had to > > make that kind of decision at runtime. > Why not? The penalty is a small increase in the size of the > binary. For certain architectures, for instance PDP-11 and 8086 small memory model, that "small increase" may make the difference between having the program run or not. There have been all too many programs posted that are "just a little too big" for the PDP-11 to dismiss this consideration. -- Name: Peter da Silva Graphic: `-_-' UUCP: ...!shell!{graffiti,baylor}!peter IAEF: ...!kitty!baylor!peter Volume-Number: Volume 3, Number 29
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (11/23/85)
Date: Tue, 19 Nov 85 20:57:51 EST From: Dan Franklin <dan@BBN-PROPHET.ARPA> > I have another argument against the desirability of these constants. It does > not allow people to do implementations that don't have any limitations (other > than availability of resources). It would be fairly easy to design a system > that would allow you to have an "unlimited" number of files, by allocating > a new table when the current table gets full. Even given such a system, I think it would still be desirable to place SOME limit on the number of open files per process to limit the consequences of error. A runaway program could conceivably open an unlimited number of files and use up the common resources (and also make it difficult to kill the process). Limiting a process to 500 or so open files seems like a good idea (just like most systems put some huge, but definite, limit on the size of a user's stack). This arbitrary limit would be the one that the limit facility would return. Dan Franklin Volume-Number: Volume 3, Number 38