[Top][All Lists]

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

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

From: Simon Goldschmidt
Subject: [lwip-devel] [task #6935] Problems to be solved with the current socket/netconn API
Date: Thu, 24 May 2007 12:26:06 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv: Gecko/20070309 Firefox/

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:


  Nachricht geschickt von/durch Savannah

reply via email to

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