> 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 _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
