Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
I found issues (lead to often tcp connect failure in wiced_http_get) if i'm trying to call wiced_http_get on more than one threads... From the look of wiced_http_get it seems Thread safe but i cannot be 100% sure. This issue can only be reproduced if i leave it running for hours with 2 thread calling wiced_http_get with 1 seconds delay after operation return (either success or failure). Does anyone has any idea?
Its not thread stack size issue, i use 2 thread, one which i created with 8K of stack size while the other one is using the pre-created network thread (i believe its 6K of stack size). Each thread does not call the https get function more than once since its a blocking function.
It might make sense to print the error message at the NetX_Duo level, if an error returned by any NetX_Duo function called inside wiced_tcp_connect(). We are mapping the NetX_Duo errors to Wiced Errors; so it would be better to get the Netx_Duo error itself.
We use a unified thread to access all HTTP request to go around this issue, we haven't had the time yet to dig deeper to find the concurrent HTTP access issue. I will feedback when we come back to check this issue, however, this can be easily reproduced from my original post so anyone who is interested can also help to check this issue.