lwip-devel
[Top][All Lists]
Advanced

[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/





reply via email to

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