[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-commits] [SCM] lwIP - A Lightweight TCPIP stack branch, maste
Re: [lwip-commits] [SCM] lwIP - A Lightweight TCPIP stack branch, master, updated. master_at_STABLE-2_0_0-736-g10a5afe
Thu, 22 Jun 2017 15:13:09 +0000 (GMT)
The idea I was thinking of wouldn't execute the callback inside the tcpip_callback() function and instead it would only queue it to be later executed during UNLOCK_TCPIP_CORE().
An example execution (using the loopback send case) might look like:
tcpip_callback_with_block((tcpip_callback_fn)netif_poll, netif, 0); <-- netif_poll and parameters are placed on delayed execution queue only
lwip_netconn_do_send(...); <-- finishes execution/returns
UNLOCK_TCPIP_CORE(); <-- delayed queue is processed before releasing mutex, netif_poll is ran
tcpip_send_msg_wait_sem and netconn APIs finish and return
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
On Jun 22, 2017, at 05:24 AM, Dirk Ziegelmeier <address@hidden> wrote:
IMHO I can't do that - the problem is still that the actual work is being done in the caller's thread, this is what I try to avoid. Currently, the semantics of tcpip_callback is to enqueue something and return, which is a very short operation. Doing more than that before the call returns is a semantical change.
- Re: [lwip-commits] [SCM] lwIP - A Lightweight TCPIP stack branch, master, updated. master_at_STABLE-2_0_0-736-g10a5afe,
Joel Cunningham <=