Messages in this thread |  | | Date | Sun, 5 Jan 1997 20:22:20 +0000 (GMT) | From | Mark Hemment <> | Subject | Re: 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 ------------------------------------------------------------------
|  |