Xref: utzoo unix-pc.general:5405 comp.sys.att:9520
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!mips!pacbell!dplace!djl
From: djl@dplace.UUCP (Dave Lampe)
Newsgroups: unix-pc.general,comp.sys.att
Subject: Re: Maximum open file descriptors in 3.51m kernel
Message-ID: <560@dplace.UUCP>
Date: 6 May 90 19:23:54 GMT
References: <1990May5.174807.7858@hybrid.UUCP>
Followup-To: unix-pc.general
Organization: Dave's Used Software Works, Livermore, CA
Lines: 33

mdapoz@hybrid.uucp (Mark Dapoz) writes:

>I seem to be running into a problem with the maximum number of open files
>the 3.51m kernel can handle.  I've bumped the parameter nfile to have a
>value of 300 but whenever I run the following program it can only open
>a maximum of 77 files.

>main()
>{
>	int x=0;

>	while (fopen("/dev/null", "r") != 0)
>	    x++;
>	printf("%d\n", x);
>}

>Now, the default minimum value for nfile is 80 which is suspiciously close to
>77

I can't run 3.51m so I can't test this but I think the problem is the standard
I/O library.  Notice that you are using fopen, not open. Before fopen even
attempts to open the file it checks to be sure that there is an available
iobuf structure.  The limit in stdio is obviously set to the default for the
kernal.  Then reason you only get 77 is because you still have stdin, stdout
and stderr open. If you have source for the library it is easy to fix, without
it you can try changing _NFILE in stdio.h but I suspect that is an output
parameter, not an input parameter.  There was source for a stdio replacement
posted to alt.sources by Steve Summit in February.
-- 
Dave Lampe
{ames | lll-tis | sun | pyramid}!pacbell!dplace!djl
(415) 455-1571 (H)
(408) 986-9770 (W)