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

[address@hidden]

Joel Cunningham wrote:
> The PCB iteration is a good point to contrast.  I would expect input 
> packets to be incoming at a higher frequency then socket API calls
>
> If we add the same “caching” feature that our PCB lists have, where 
> the most recently used are moved to head of the list, that may negate 
> some of the performance loss

I agree. Also on the maintenance part.

However, I'm still not fully tempted we should change the sockets array 
to a list. Using lwIP in the Hurd might be a cool thing to do, but after 
all, this is *not* our main target. Do other (i.e. "normal") targets 
benefit from this change? They could, if they are using MEMP_MEM_MALLOC 
only - because if we'll add this functionality, we would have to add a 
new MEMP pool for sockets for the standard (i.e. non-limited) behaviour.

I think we'll have to decide: is it worth to make performance and memory 
footprint worth on nearly all platforms to let MEMP_MEM_MALLOC platforms 
benefit?

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?

Simon