On Mon, 2009-09-21 at 12:21 +0200, Kesten, Joerg wrote: > > > Multithreaded sockets is something that is not well supported on lwIP, > > so I'm not surprised you've had to add some extra locks. If you're > I am (painfully ;-)) aware of that. A completely other issue, but is > it right that there is currently no intention to support this as there > seem to be only very few people needing this? At least this was the > impression I got from reading several discussions related to this on > the homepage (bugs section)
I would like to get lwIP to the point where different threads using separate sockets is fine, but not different threads using the same socket. There is a move towards a re-write of the sockets layer, and I expect that this would be solved as part of that. If there's a simple bug we can fix in the meantime to improve things though I would be happy to see it included. > > How do you call netif_add()? This function specifies which function > > will be called (stored in netif->input) when a packet is received by > > ethernetif_input(). > Here is my call to netif_add: > netif_add( netif, &ipaddr, &netmask, &gw, NULL, ethernetif_init, > tcpip_input)); That looks fine: tcpip_input should serialise received packets so they are not processed at the same time as sending ones. The only other contender would be TCP timer processing happening in parallel with a data operation. Perhaps that is worth checking, although timer events are supposed to be dealt with by the tcpip module in your situation without the need to call them externally. Looking at the code I think this could be the problem: timers are processed when a thread blocks, so if one of your threads blocks (see comment to sys_timeout() for full details) and this could be a different thread to the one that owns the connection. When the timer expires and the tcp_tmr() function is called to process TCP operations, this could therefore happen in parallel with a data operation on the same connection. I'm not sure what the best way to fix this is though: it will need some thought. > > No, if you're using the APIs correctly you shouldn't need to manually > > lock these lists. > Ok, thinks. > BTW: There is this LWIP_TCPIP_CORE_LOCKING define in opt.h which > obviously should not be used and therefore I did not change the > default here... but to me it sounds as if this could be exactly the > thing I'd need here? Frederic Bernon is the expert on that and how it should be used, but it might be worth trying. Kieran _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
