lkml.org 
[lkml]   [1997]   [Jan]   [7]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateSun, 5 Jan 1997 20:22:20 +0000 (GMT)
FromMark Hemment <>
SubjectRe: How to increat [sic.] max open files - some answers
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
------------------------------------------------------------------

\
 
 \ /
  Last update: 2005-03-22 12:38    [from the cache]
©2003-2008