Hi,
I am developing an application that uses lwIP's sockets interface.
Since I needed non-blocking connect, I implemented one, see patch
number 6860 ( https://savannah.nongnu.org/patch/index.php?6860 )
I tested my system using Intel's threads-checker, which detected a
thread-safety problem in lwip's code, regarding conn->err handling.
This field is used by many netconn functions (i.e. netconn_send,
netconn_getaddr, etc.) as the value to use for the return value.
However, this field might be changed asynchronously due to network
events. Since the variable is not even properly synchronized, it means
that the return values from various functions could be undefined.
Additionally, based on further examination of the code, it seems that
this variable is used for 2 very different purposes – it is used both
to carry "return value" information from the tcpip_thread back to the
calling thread, and to hold "connection global error state"
information. As a result, attempting to use netconn_getaddr on a
non-connected UDP socket will set conn->err to ERR_CONN (considered
"fatal"), causing subsequent calls to netconn_recv to fail. This is
clearly an unwanted side-effect that should be prevented.
It seems to me that the proper solution to the problem would be to use
the api_msg_msg struct to convey the error/return code information for
api calls, and keep conn->err as the global error state of the
connection, but use SYS_ARCH_PROT_* wrappers to make sure it is
providing a coherent status for the connection global state, for use
by netconn_recv and netconn_send. Additionally, there should be a way
for netconn_recv and netconn_accept to provide error information to
the caller – as of time being they can either return a pointer or a
NULL pointer to indicate error, but as for the details of the error,
it is up for the caller to guess.
What is your opinion on this subject? Is there a synchronization
mechanism that we missed which prevents said problems from happening?
Regards,
Laura Garrett
------------------------------------------------------------------------
_______________________________________________
lwip-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-devel