Re: apache style squid?

--MimeMultipartBoundary
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT

From: Anthony Baxter <arb@connect.com.au>
> (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.

 Maybe you're right, and I said AFAIK. But I don't see why select() should care
 about FD_SETSIZE on Solaris. All it operates with is number of files passed
 to it. It is macros FD_SET, FD_CLR etc. that depends on this and apps allocating
 enough space for FD array. man page says you should define larger FD_SETSIZE
 before including types.h, I can't find where it says select() cannot cope with
 more than 1024 files?

> > Basic reason is that you can break lots existing stuff, select() has large
>
> 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
   right.

> > 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?

 but they are allowed?! You can easily max FD's up to 32000 on Solaris
 if you feel it right. Only you'll get slow with that, I guess because there
 is linear search every time you operate with them. Of course you can
 go straight up, but the idea is that you WISH to change approach with that
 much files.

 Just my thoughts...

 ----------------------------------------------------------------------
  Andres Kroonmaa mail: andre@online.ee
  Network Manager
  Organization: MicroLink Online Tel: 6308 909
  Tallinn, Sakala 19 Pho: +372 6308 909
  Estonia, EE0001 http://www.online.ee Fax: +372 6308 901
 ----------------------------------------------------------------------

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