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

[Simon Goldschmidt]

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

> The suggestions you make seem to be along the lines of fixing up the
existing sockets API.

Whether this gets fixed up in the current implementation or in a new one is a
question to be asked, but it would work for both!

> (ii) and not require additional stuff inside the stack to support it on the
raw API

While locking the whole stack core would work, I would (in a second stage)
also implement more locks (as defines so raw-api-only would not require them)
to let one thread run in ARP while another one puts together TCP segments.

> However, this is very low priority.

I agree. But talking about it doesn't hurt. And that way, we get an
impression whether to 'repair' the old api or impelment a new one.

> (i) do a better job of supporting the sockets API than we have already

I think in terms of speed and prioritization, we can. Otherwise, the sockets
API seems kind of OK to me (if you don't count the multithreading issue from
patch #5960).

I agree speed is not the main goal for lwIP. But what I want is not gaining
much wire-speed but spending as little time as I can with TCPIP processing
(because in our device, it's not the most important thing to do).

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/