[lwip-devel] [bug #52747] mdns resp: separate the announce function and add netifapi support for it

[Douglas]

Follow-up Comment #2, bug #52747 (project lwip):

A significant part of the change was to stop announcing on calls to
mdns_resp_add_netif and mdns_resp_add_service, see "The interface setup
functions no longer invokes an announcement."

There is currently no safe way to call these setup functions from the tcp
thread, and as-is it calls into the guts of the mdns code in the context of
the caller and that requires all these threads provision for the significant
stack allocation requirements of the mdns code. This was the problem trying to
be solved, and remains to be solved.

What would people think about having a queue for tasks to be run in the tcp
thread. Then the announcements could be queued to run there. This same
approach could be used for similar challenges. This could work alongside core
locking, so core locking could be used for light weight functions that can be
run in the caller thread context and if they trigger any heavier weight code
then they could queue that to run in the tcp thread.

The core locking could then be used for these mdns setup function, and if they
are to trigger an announcement then that could be queued.

>From other discussions it appears that core locking might become mandatory,
yet there might still be a need to be able to queue tasks to run in the tcp
thread just because they are too heavy to run in the caller context.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?52747>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/