[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: address@hidden
Subject: Re: [lwip-devel] Removing the restriction on number of sockets
Date: Tue, 8 Aug 2017 21:30:43 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]