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

[Stian Skjelstad]

On Wed, Aug 9, 2017 at 7:52 AM, Joan Lledó <address@hidden> wrote:

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?

Since FD numbers are shared among threads in LwIP (everything is basically one process), the size of the fdset limits by the biggest possible FD number when using a bitfield. In theory, a user (application) can tweak there local fdset to be bigger, since one of the parameters to select is "maxfd". Normally, the fdset is only used for select, but of course any programmer is free to use if for other purposes, since the macros are available. 

On Linux, FD_SETSIZE == the default application filedescriptor limit. This limit you can increase. Side effect is that you can have filedescriptors which will cause memory writes to memory outside the fdset when using the API as is...

--

Stian Skjelstad