On Jun 22, 2017, at 10:35 AM, goldsimon <address@hidden> wrote:
Joel Cunningham wrote:
Functionally this should be equivalent to TCP/IP thread context
switching after lwip_netconn_do_send() has completed without actually
running netif_poll on another thread
Equivalent only as long as tcpip_thread has a higher prior and the queuing would not be done from interrupt context...
True. Just so I understand, was the point of the original commit (which has now been reverted) to run tcpip_callbacks on the calling thread for the core locking case?
I do wonder if the current system (using the TCP/IP thread for callbacks) would be better for an SMP system where another thread could complete the callback in parallel once the thread posting the callback releases the core lock.
Joel