RE: [lwip-users] issues with resending out of order segments

[Kieran Mansley]

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