You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Your code fails if the CONFIG_LWIP_CHECK_THREAD_SAFETY option is activated, because you do not use the thread-safe APIs.
I tried modifying the code by using the netifapi_netif_* functions to solve this thread safety issue but I don't understand why the peer keeps being down.
My understanding is that these functions are just wrappers to run the original netif_* function inside the tcpip_thread context, so it should behave like the original functions.
@trombik: I will continue debugging this but I wanted to have your opinion about this potential thread safety issue, and if you understand why it could fail when using the thread-safe API.
The text was updated successfully, but these errors were encountered:
Thanks for reporting the issue. When I ported, thread safety was not in my mind. As I am not an expert in lwip stack, I am certainly not in a position to comment on thread-safe APIs. Moving to newer esp-idf APIs has been in my TODOs list, but I have been in a difficult situation in my personal life.
Your code fails if the CONFIG_LWIP_CHECK_THREAD_SAFETY option is activated, because you do not use the thread-safe APIs.
I tried modifying the code by using the netifapi_netif_* functions to solve this thread safety issue but I don't understand why the peer keeps being down.
My understanding is that these functions are just wrappers to run the original netif_* function inside the tcpip_thread context, so it should behave like the original functions.
@trombik: I will continue debugging this but I wanted to have your opinion about this potential thread safety issue, and if you understand why it could fail when using the thread-safe API.
The text was updated successfully, but these errors were encountered: