Re: MAXFD frustrations

Still true. See http://devel.squid-cache.org/hno/linux-lfd.html

Short version: Increasing the FD_SETSIZE on Linux requires hand-editing
the __FD_SETSIZE definition /usr/include/bits/types.h and to set the
ulimit in your shell... The kernel is neutral, the C library is
neutral, but the include files are not...

We cannot relax the definition of Squid_MaxFD just yet as there still is
some parts of Squid depending on fd_set. When Squid is cleaned from all
direct and indirect FD_SETSIZE references such as fd_set then we can
forget about the issue when using poll.

It probably would also be wise to bugger the GNU Libc people a little
about making FD_SETSIZE configurable like most other OS:es..

Note: There is a patch pending on squid-dev for removing the remaining
fd_set uses. A quite likely candidate for 2.6.

Regards
Henrik

Duane Wessels wrote:
>
> I'm running some tests on a linux box and had some trouble getting
> squid to use more than 1024 descriptors. In src/squid.h we have:
>
> /* Cannot increase FD_SETSIZE on Linux */
> #if defined(_SQUID_LINUX_)
> #undef CHANGE_FD_SETSIZE
> #define CHANGE_FD_SETSIZE 0
> #endif
>
> Is this still true for modern Linux versions?
>
> Also in src/main.c we have:
>
> if (FD_SETSIZE < Squid_MaxFD)
> Squid_MaxFD = FD_SETSIZE;
>
> Seems to me that we can relax these restrictions if Squid uses
> poll() instead of select(), no? Way back when, the whole
> reason for all these checks were to make sure that Squid didn't
> exceed some array bounds in select code. I don't think poll
> has that problem though...
Received on Mon Dec 03 2001 - 11:57:42 MST