Re: [lwip-commits] [SCM] lwIP - A Lightweight TCPIP stack branch, master, updated. master_at_STABLE-2_0_0-736-g10a5afe

[Joel Cunningham]

Dirk,

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:

lwip_sendto(...);

  netconn_send(...);

    netconn_apimsg(lwip_netconn_do_send,...);

      tcpip_send_msg_wait_sem(...);

        LOCK_TCPIP_CORE();

        lwip_netconn_do_send(...);

          udp/ip_output(...);

            netif_loop_output(...);

              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

Joel

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.

Dirk