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!gatech!seismo!ut-sally!std-unix
From: std-unix@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re:  OPEN_MAX and other constants - are they desireable?
Message-ID: <3635@ut-sally.UUCP>
Date: Fri, 22-Nov-85 21:11:26 EST
Article-I.D.: ut-sally.3635
Posted: Fri Nov 22 21:11:26 1985
Date-Received: Sun, 24-Nov-85 05:33:10 EST
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 21
Approved: jsq@ut-sally.UUCP

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