Re: apache style squid?

(Hmmm, going off on a tangent here.)

>>> "Andres Kroonmaa" wrote
> AFAIK 1024 limit for select() is not tied to OS, but too many apps assuming
> FD_SETSIZE is 1024. Solaris select() converts to poll() anyway, thus Solaris
> select() is not an issue. Recompile your app with different FD_SETSIZE and
> you are ok,

The select() library call would also need to be recompiled with a
different FD_SETSIZE - it's set to 1024. (That's _why_ we did the poll()
stuff). Unless the select man page is lying, this still isn't fixed in
2.6.
 
> Basic reason is that you can break lots existing stuff, select() has large
> overhead, on Solaris you want to go poll() anyway, especially when you write
> something FD intensive. With poll() going up to 8192 is no problem.

Except that setting the OS max # of fds to 8192 breaks various OS
applications that use select(). An example is something as simple as the
Sun compiler - it's unable to contact it's license manager when you set
the max number of fds to 8192. There's a variety of other applications
that broke, too...

> Going
> over this is discouraged for kernel resource usage and different algoritm
> should be used. I guess, idea is "use up to 4096 FD's per process, if you
> need more, use more processes"

I still see no reason for not allowing people to use higher numbers of
fds, _if_ _they_ _want_ _to_. The cost of allocating more space in the
kernel for fds might cost something, but so long as you're aware of that,
and you're happy to pay that cost, who cares?

Anthony
Received on Tue Jul 29 2003 - 13:15:43 MDT