Re: How to increat [sic.] max open files - some answers

Mark Hemment (markhe@nextd.demon.co.uk)
Sun, 5 Jan 1997 20:22:20 +0000 (GMT)

On 4 Jan 1997, Miquel van Smoorenburg wrote:
> Mark Hemment <markhe@nextd.demon.co.uk> wrote:
> >On Fri, 3 Jan 1997, Richard B. Johnson wrote:
> >Lets clear up one BIG misunderstanding;
> > FD_SETSIZE <= sysconf(_SC_OPEN_MAX)
> >Note the '<' part! (for those who write non-portable code, sysconf(...) =
> >NR_OPEN).
> >
> >OK, under Linux FD_SETSIZE does equal the max num of open files. But try
> >it out on UnixWare/Solaries (and other SVR4 derived systems). XPG/4
> >states select() only supports fds upto FD_SETSIZE.
>
> Ehm. No.

OK, thanks for proving I'm human....

> posix_types.h:#undef __FD_SETSIZE
> posix_types.h:#define __FD_SETSIZE 1024
> posix_types.h:#define __FDSET_LONGS (__FD_SETSIZE/__NFDBITS)
> time.h:#define FD_SETSIZE __FD_SETSIZE

But what happens when 1024 is not enough, or 2048...

Under an SVR4 derived system, when the num of open descriptors is raised
FD_SETSIZE does not magically change in the library/apps.

select()s FD_SETSIZE is a limitation, which in _most_ cases can be
programmed around (I know, I've had to do it!) while still having a large
(pick your number, 16384 if you like) files open.

> >For a complete solution, the poll() sys-call is needed (it's required by
> >the latested XPG/4 spec anyway).
>
> That's probably true
> Mike.

Yep, and it has no built in limitation.

markhe

------------------------------------------------------------------
Mark Hemment, Unix/C Software Engineer (Contractor)
markhe@nextd.demon.co.uk
------------------------------------------------------------------