[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-devel] [task #6994] Redesign Socket Layer with LWIP_TCPIP_CORE_LOC
From: |
Frédéric Bernon |
Subject: |
[lwip-devel] [task #6994] Redesign Socket Layer with LWIP_TCPIP_CORE_LOCKING |
Date: |
Sun, 10 Jun 2007 19:03:47 +0000 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4 |
Follow-up Comment #4, task #6994 (project lwip):
>remove LOCK code from sys.c to be cleaner, instead LOCK/UNLOCK all
timer/timeout functions
>LOCK in tcpip_thread only when a message is processed, UNLOCK after
processing (before waiting for next message)
For these two points, in my first test, that what I did, but the current code
doesn't really affect performance, and is less "intrusive" in the current
source code. So, I prefer the current solution, even if it good be a little
bit less efficient - but it's really a little bit. It also avoid to patch
each timers function, like for the future integration of AutoIP timers. I
will measure each solution, except if others have a real preference for such
or such solution.
>LOCK in tcpip_ethinput and call ethernet_input directly (this one should be
an option since it does not work if someone calls netif->input() from
interrupt context).
Yes, even if it's not one of the first steps we have to do, it's seems to be
the good solution. Perhaps add a different tcpip_ethinput function, like
tcpip_ethinput_lock (by
symmetry with tcpip_apimsg_lock).
>The tcpip_thread is effectively used only for timeouts then.
Yes, and in this case, a new design for timers handling can be study
(avoiding to alloc/desalloc, but just reinsert the "timeout handler" in order
in the list, or just a counter and a check modulos of this counter, like in
the previous code of DHCP timers).
Note that all these previous points are more "Sequential API with
LWIP_TCPIP_CORE_LOCKING" than pure "Socket Layer".
But, before all that, is there any objections about adding a "sockets2.c"
file, to avoid patch like in lwip_sendto? I would like to remove it (the
lwip_sendto's patch) as soon as possible...
_______________________________________________________
Reply to this item at:
<http://savannah.nongnu.org/task/?6994>
_______________________________________________
Message posté via/par Savannah
http://savannah.nongnu.org/