Hi,
tcpip_api_call function will take care of everything. Its basically a wrapper function and works exactly the way Simon suggested if LWIP_TCPIP_CORE_LOCKING is enabled otherwise it will execute the function call from tcpip thread context and wait for it to finish. You can go ahead with this or you can use my original suggestion since dns_setserver is not a blocking call.
However, I am not sure if dns_setserver really needs to be protected so much as there is nothing much going on except copying of server in an array.
Regards,
Ajay Bhargav
Dear Simon and Ajay,
Thanks you so much for your attention in this matter.
I appreciate your suggestions and I evaluate them carefully. I hope to interpret correctly the three your solutions:
- LOCK_TCPIP_CORE / UNLOCK_TCPIP_CORE. They allow to access in exclusive way to TCIPIP mechanism. However, I don’t want interfere with the regular mechanisms of TCIPIP thread and of operating system;
- tcpip_callback. It allows to call a specific function inside TCPIP thread. However, tcpip_callback doesn’t expect a wait until the end of the function executed in TCPIP thread.
- tcpip_try_callback. As for the above function, tcpip_try_callback also allows to call a specific function inside the TCPIP thread. However, tcpip_try_callback doesn’t block when the request can’t be posted in the tcpip_mbox.
For these reasons I choose to use the tcpip_api_call function. In this way the caller task waits for the TCPIP operation to be completed and the modifications to the existing project are marginal.
I follow the netifapi_netif_set_addr function as example. So, I introduce:
- dnsapi_dns_setserver. Function called from non-TCPIP threads. It passes to TCPIP thread the dnsapi_do_dns_setserver function through the tcpip_api_call function;
- dnsapi_do_dns_setserver. Function called inside the TCPIP thread. It calls the dns_setserver function. So the dns_setserver is executed in thread-safe way;
- dns_server_api_msg. Structure used to modelized the message passed to TCPIP thread through tcpip_api_call function.
This solution works fine.
At this point I would like to know your position about the use of the tcpip_api_call function instead of your suggestions. Is it an equally acceptable alternative from your point of view?.
Thanks in advance.
Regards
You can write a simple wrapper function for DNS setup and use tcpip_callback to call it from TCPIP thread context. There is also tcpip_try_callback.
Ajay Bhargav
> Dear all,
>
> I would like to ask some questions about the thread-safe functions.
>
> According the http://www.nongnu.org/lwip/2_0_x/pitfalls.html page, in
> the OS mode, all the callback-style APIs function must only be called
> from the TCPIP thread.
> In the OS mode, the functions belongs to NETIF, DHCP, DNS, … modules
> require corresponding thread-safe functions to be used from threads
> different from TCPIP thread.
> For example instead of calling directly the /netif_set_up/ function it’s
> necessary use the /netifapi_netif_set_up/ function, or instead of
> calling directly the /dhcp_start/ function it’s necessary use the
> /netifapi_dhcp_start/ function.
>
> I am looking for the thread-safe function corresponding to the
> /dns_setserver /function. I am using LwIP 2.1.2, but I don’t find it.
I don't think such a function exists.
>
> At this point I would know if there is a thread-safe function
> corresponding to the /dns_setserver/ or if I should build a similar
> function myself. In this last case, which function could I take as a model?.
The simple solution would be to enable LWIP_TCPIP_CORE_LOCKING and
surround your call with LOCK_TCPIP_CORE()/UNLOCK_TCPIP_CORE().
Regards,
Simon
>
> Thanks in advance for your attention and for your suggestions.
> Regards
_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users