LwIP and multithreading

From lwIP Wiki

a- lwIP core isn't thread safe. If we have to use lwIP in a multithread environment, we should (or HAVE TO) use "upper" API layers (netconn or sockets). raw api need to protect yourself the core.

- sockets generally can't be used by more than one application thread (on udp/raw netconn, do a sendto/recv is currently possible).

- concurrent calls on some upper operations have to be handled directly by application: socket, bind, connect, setsockopt and close. It's the lwIP role to handle that (by example, it will be difficult to know if a "int socket" is always same between close/socket calls:

 Task1
  int s1=socket() (tell s1=5)
 Task1,Task2
  use s1 with send,recv (ok, it could be possible).
 Task2
  closesocket(s1)
 Task3
  int s2=socket() (and... it could be s2=5)
 Task1
  send(s1) !!!! Problem, s1 would not the same proto/port than the first we open, 
           !!!! but only application can know that !!!!

- some operations could be changed to be thread-safe : recv, recvfrom, send, sendto... To enable fullduplex protocols. We have to move some processing from netconn/sockets to api_msg, but it's possible, and even can be faster... But it's not yet possible.

- some others informations to remember: some special functions can also cause problem with multithread: netif_xxx and dhcp_xxx. These functions used same variables than tcpip_thread. Some cases:

- if an "application" thread remove an netif from list, during tcpip_thread is running, so, you can get a crash. Adding two netif in the same time can cause to lost one of interface (https://savannah.nongnu.org/bugs/?19347).

- if an "application" thread stop dhcp on an interface, because the netif's dhcp field can be used by dhcp's timers (runnning in tcpip_thread context), you can get a crash (https://savannah.nongnu.org/patch/?5798).

- for the two previous points, you could use "netifapi" which is very close than "netif" and "dhcp" API.