Henrik Nordstrom writes:
>Duane Wessels wrote:
>
>> I'm happy to put some limit in the loop. 8192? 16384?
>
>And what is wrong with using the available interfaces (sysconf and/or
>getrlimit) if available? I would not trust opening more files than these
>reports even if possible (an obvious sign of a falty attemt to increase
>the kernel limit beyond what the system can support, which is quite
>likely to fail in various ways).
We have one example where getrlimit() returns useless information.
On AIX 4.2.1, getrlimit() returns "infinity." I either have
to add a special condition for AIX to not use getrlimit(), or I have
to detect the infinity and then try one of the other techniques.
I already think that little chunk of code is too complicated,
especially when I have to handle all the ways that it fails for
particular systems.
My goal is to make it simpler -- to find a lowest common denominator.
>If I understands things correctly, the purpose of this configure test is
>to find the systems upper limit of FD_SETSIZE for systems using
>select(). For systems not using select() (i.e. poll) we may equally well
>use runtime detection using sysconf/getrlimit instead.
It might be possible to use run-time settings for poll(), I haven't
investigated that. We would have to make minor changes code like this:
comm_select.c: struct pollfd pfds[SQUID_MAXFD];
Hm, instead of a loop, what about a binary search using dup2()
starting at some large number like 16384.
Duane W.
Received on Tue Jul 29 2003 - 13:15:57 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:12:05 MST