[lwip-devel] [task #6935] Problems to be solved with the current socket/netconn API

[Jonathan Larmour]

Follow-up Comment #6, task #6935 (project lwip):

Re comment #14: Speed versus footprint is usually a trade-off. But it's
harder to shrink a complex implementation, than it is to speed up a small
implementation. So I suggest ensuring that footprint is first, with speed
only in mind, than the other way round.

I do sometimes wonder that lwIP is being used by some people not because of
the "lw" but because there just aren't many free easy-to-port TCP/IP stacks
out there.

In terms of implementing in terms of mutexes, I'll just draw attention to
comment #22 of patch #5960.

I think it's worth mentioning that there could be different grains of
locking, that could be options.
1) Lock the whole stack
2) Lock each connection
3) Lock each relevant chunk of functionality.

Each one in turn would increase the footprint, but by having different
granularity, overall performance with multiple threads could be improved.
Only with 3) would you be able to do things like send and receive on the same
socket from multiple threads. But many people don't need that, so 1 and 2
would reduce both complexity and footprint for those.

Function-like macros could be used to control it so that we don't have a mess
of ifdefs - depending on the user's chosen options, some will evaluate to
nothing. So for example, on entry to an API function, something like
LOCK_CONNECTION(conn) would be called, which in some configurations would
actually lock the whole stack, not just the connection.

Just some thoughts anyway.



    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/task/?6935>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/