Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site bty.UUCP
Path: utzoo!watmath!clyde!cbosgd!ulysses!mhuxr!mhuxt!houxm!whuxl!whuxlm!whuxcc!infopro!bty!std-unix@ut-sally.UUCP (Moderator, John Quarterman)
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: <185@bty.UUCP>
Date: Thu, 14-Nov-85 04:41:31 EST
Article-I.D.: bty.185
Posted: Thu Nov 14 04:41:31 1985
Date-Received: Sat, 16-Nov-85 01:10:41 EST
References: <3430@ut-sally.UUCP>
Sender: root@bty.UUCP
Organization: BTY, Inc., Rockaway, NJ
Lines: 19
Approved: jsq@ut-sally.UUCP

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