Comment # 18 on bug 1165351 from Thorsten Kukuk

(In reply to Franck Bui from comment #16)

> Indeed that was my thinking too and it's actually how glibc implements
> getdtablesize(3). It looks like there might be a bug here therefore I would
> suggest to send a patch upstream that make the code use the soft limit.

glibc is using sunrpc, not ti-rpc. You cannot compare that functions, as the
code calling this function is different and use it different. With the problem,
that connections could be ignored if the number of the fd does not fit. One
common problem since the day Linux supports more than 1024 file descriptors for
a process.

But you are right that TI-RPC needs to be adjusted, as written, the code
calling __rpc_dtbsize() needs to be rewritten. Best to not allocate that huge
array, but in every case it needs some sanity checks if the filed escriptor is
inside the table or outside.