Hi Robert,
> right now I have the threads structured like this (highest to lowest > priority): > > - highest priority is the thread for the HW interface, it > takes lwip's packets from a queue and passes them to the HW > (or reads them from the HW and passes them to lwip...) > - the next thread is the timer thread, which only calls > tcp_tmr and etharp_tmr periodically > - then there's lwip's tcp/ip thread > - and the lowest thread is the application doing the the > send/recv calls. The threads look good to me except for one thing: As far as I know, you must not call the timers from a different thread. The simple reason for that is that if calling from another thread (which has a higher prio than the tcpip-thread), the timer can interrupt e.g. tcp processing and call the same function twice, resulting in corruption of global variables. For arp it's nearly the same (arp table gets modified). Lwip is not protected against multiple threads running in the stack's context at the same time. Instead, the timers should be called every time the tcpip-thread waits for a semaphore, in which case it is not in any stack-function and the timer functions can safely be called. This is the way Thomas described it in his last post. > Is there anything like a suggested model for those thread priorities? None that I know of, but you got it right, I think. I have it exactly the way you have and it's working fine. You shouldn't give your application thread a higher prio than the stack, though. This would block e.g. tcpip timers from running correctly if your application does a lot of other things while not using sockets. Simon. _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
