Re: OPEN_MAX & configure[.in]

On Wed, Dec 30, 1998 at 01:00:16PM +0100, Henrik Nordstrom wrote:

> Hard to tell. OPEN_MAX is defined as a limit on how many files a
> single process may open, but when can this be trusted?

I think _almost_ always it can be trusted. Only, there is alanc
development linux tree which dynamically allocates FDs as required
hence isn't practially limited except by the ulimits and the kernel
wide limit.

I think we can probably trust the limits in this case, although they
could in theory be higher than the kernel wide limit.

> That to is not a good idea. Hard probing should be avoided if
> possible as it may have a servere impact on the host. And on some
> OS:es number of filedescriptors is effectively unlimited.

ok, good point.

> My bet is that rlimit should be trusted as much as possible, with
> warnings if this is higher than OPEN_MAX or NR_OPEN.

agreed

> If select is used then the lowest of rlimit and FD_SETSIZE should
> be used.

what if you redefine FD_SETSIZE -- this works for most/all OSs I know
off (although you may get compile time warnings)

> If poll is used then we do not need to care about FD_SETSIZE and
> conseqently FD_SETSIZE should be ignored if poll is used.

ok... presently this doesn't happen. I'm trying to track down another
ugly, once thats nailed I'll make a patch for the above.

-cw
Received on Tue Jul 29 2003 - 13:15:55 MDT