This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Allow customizing of __FD_SETSIZE


On Fri, Jun 11, 2010 at 4:53 AM, Keisial <keisial@gmail.com> wrote:
>> The kernel __kernel_fd_set only supports 1024 file descriptors.
>>
>> (a) Have you patched your kernel to support more?
>>
>> (b) What are you doing for old programs that would only support 1024,
>> how does the kernel detect those programs and avoid using the
>> unavailable additional file descriptor bits?
>>
>> Unfortunately your problem is much more complicated than simply
>> increasing the value in a header. This is an ABI issue.
>>
>> Does that answer your question?
>>
>> Cheers,
>> Carlos.
>>
> The first select parameter (nfds) should take care of it.

Yes, you are right, I see fs/select.c does use nfds to compute
everything, and the kernel uses fd_set_bits instead of fd_set to allow
scaling of the size of the fd_set.

So in this case it seems that there is no ABI issue in the kernel,
that as long as userspace passes the right value for nfds, that the
kernel scales up.

I checked in glibc, and I see no serious problem using a larger
fd_set. However the sunrpc code uses fd_set and therefore that API
will expect a normal sized fd_set.

Unfortunately changing fd_set still changes the userspace ABI, which
expects a fixed fd_set size.

You really have two options:

(a) Design a way to handle larger fd_set that does not break ABI

(b) Switch to using epoll.

As it stands I don't think your bugzilla entry will ever be accepted
by upstream because of the ABI issues.

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]