Re: [lwip-devel] Removing the restriction on number of sockets

[Joan Lledó]

2017-08-08 23:09 GMT+02:00 Stian Skjelstad <address@hidden>:
>
> Apart from that, the "fd_set" issue still remains to be solved. The only way
> I can think of to fix it is to make "fd_set" an array of sockets instead of
> a bitfield (FD_SET adds an element, FD_CLR and FD_ISSET have to iterate the
> set). However, that would mean there's either an upper limit on sockets in
> such an fd_set: what does FD_SET do if the maximum number is reached?
> Assert-fail? Use the heap to allocate more memory?
>
>
> UNIX systems where you can adjust the fd limit to be bigger than the default
> size of a fdset, it is common to use the poll() api instead in order to be
> cross platform. At least that is my experience from using the socket API.
>

Is fd_set used for other purpose than calling select()? If not, we
should be able to continue using the current bitfield, as it only
limits the number of sockets used in one call to select(), not the
amount of sockets available.

I did a quick research to know whats the value of FD_SETSIZE on other
systems. In Linux[1] it is 1024, and 256 in the Hurd[2]. In LwIP, the
user can set FD_SETSIZE in cc.h based on the target resources, right?

>
>
> Stian Skjelstad
>
>
> _______________________________________________
> lwip-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-devel
>

--------------------------
[1] 
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/x86/bits/typesizes.h;h=73962eb85905b0030017bbc24085f073fdd9a7f3;hb=HEAD#l92
[2]https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/bits/typesizes.h;h=e87ad60517d9e16d39551580b24f97875565f0fd;hb=HEAD#l65