Re: OPEN_MAX & configure[.in]

Chris Wedgwood wrote:

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

There are several occations where OPEN_MAX can not be trusted:

* Someone is patching their kernel to support more filedescriptors.
* The OS is effectively unlimited (or a lot higher than in earlier
release), but keeps a "dummy" OPEN_MAX for source compability. On these
OS:es OPEN_MAX will probably be equal to FD_SETSIZE, for the same
reasons as FD_SETSIZE remains at the old value (object file
compability).

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

True. But if you are referring to the system wide (all processes) limit,
then there is no way to figure this out in a portable way short of
probing.. Lets assume that the administrator knows how to configure a
system.

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

Redefining FD_SETSIZE does not work on all OS:es. Doing this is kind of
"magic". Anyway, it is better to get a system that supports poll() than
fiddling around with redefining of FD_SETSIZE and other "stupid" limits
if you need support for large amounts of filedescriptors.

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