About: LwIP and multithreading   Sponge Permalink

An Entity of Type : owl:Thing, within Data Space : 134.155.108.49:8890 associated with source dataset(s)

The 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). When using raw API you need to protect yourself the core. Some others informations to remember: * Some special functions can also cause problems regarding multithreading: netif_xxx and dhcp_xxx. These functions use the same variables as tcpip_thread. Other examples To avoid the previous 2 problems, you could use "netifapi" which is very close to "netif" and "dhcp" API.

AttributesValues
rdfs:label
  • LwIP and multithreading
rdfs:comment
  • The 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). When using raw API you need to protect yourself the core. Some others informations to remember: * Some special functions can also cause problems regarding multithreading: netif_xxx and dhcp_xxx. These functions use the same variables as tcpip_thread. Other examples To avoid the previous 2 problems, you could use "netifapi" which is very close to "netif" and "dhcp" API.
dcterms:subject
abstract
  • The 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). When using raw API you 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 problems regarding multithreading: netif_xxx and dhcp_xxx. These functions use the same variables as tcpip_thread. Other examples * If an "application" thread removes a netif while tcpip_thread is running, this may result in a crash. Adding two netif at the same time can result in a missing interface (). * If an "application" thread stops 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 (). To avoid the previous 2 problems, you could use "netifapi" which is very close to "netif" and "dhcp" API.
Alternative Linked Data Views: ODE     Raw Data in: CXML | CSV | RDF ( N-Triples N3/Turtle JSON XML ) | OData ( Atom JSON ) | Microdata ( JSON HTML) | JSON-LD    About   
This material is Open Knowledge   W3C Semantic Web Technology [RDF Data] Valid XHTML + RDFa
OpenLink Virtuoso version 07.20.3217, on Linux (x86_64-pc-linux-gnu), Standard Edition
Data on this page belongs to its respective rights holders.
Virtuoso Faceted Browser Copyright © 2009-2012 OpenLink Software