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

[Kesten, Joerg]

> However, I don't think much changed in tcp_rexmit() for 1.3.1, and the
> code looks OK at first glance.
> 
> I suggest you take a good look at the unsent list before and after a
> call to tcp_rexmit and see if you can work out what goes wrong.
I will try to do so, but up to now I did not gather any useful data here


 
> It may be that there is another thread coming in and trying to add
> something to the unsent list while tcp_rexmit is modifying it.  This
> would fit with what you see, and would be caused by having a sending
> application thread active in the stack at the same time as a received
> packet is being processed.  How do you interface to the stack?  i.e.
> which API, and how does you driver pass received packets up for
> processing?
This is something which is very likely to happen in my application.

I am using the sockets API in a multithreaded environment, and in fact already 
ran into several issues with synchronization.
I already added additional locks so that only one thread is allowed to call 
"send", and mutex'ed sending and receiving in one connection.

But I'd assumed that receiving data at such a low level is something which can 
occur anytime when sending, even in a single threaded application?

In the driver there is a special thread which pends on incoming data and calls 
ethernetif_input

Is there any "natural" place were I could/should lock access to the unsent list?

Thanks,
Jörg