|Subject:||Re: [lwip-users] critical section protection + timer issues|
|Date:||Fri, 18 Feb 2005 18:28:19 -0800|
|User-agent:||Mozilla Thunderbird 1.0 (Windows/20041206)|
I think that I have been answering a different question than the one
that you are posing here. I was trying to address the possibility that
you might or might not find the sys_timeout features useful in threads
of your own. You are asking more fundamentally, how can lwip's raw
interface work in a multithreaded system.|
I've never used the raw interface on a multithreaded system. My understanding is that those who do use it are either running on a system that does not employ multi-threading or have contrived their systems in such a way as to run all of their tcp operations out of tcp callbacks. Neither of these approaches seemed appropriate for the systems I have implemented thus far.
Like you, I am operating in a multi-threaded environment. I use the "netconn" api from api/api_lib.c in one of my projects and the Berkeley Sockets api from api/sockets.c in another. I personally prefer the "netconn" api, but lots of people who are already familiar with Berkeley Sockets api prefer that. For the most part, the sockets api just provides a wrapper for the netconn api.
Both of these api's presume that they will be called from threads other than the tcpip thread. They communicate with the tcpip thread by sending messages to it. They have blocking calls, which you may or may not find convenient. They are exactly what I want.
It is quite possible that other users will differ with me on this, but I strongly suggest that you look at the above mentioned api's and abandon your use of the raw api. The old (and somewhat outdated) document that Adam wrote provides good samples of how each of these higher level api's might be used. You should look at that document to get the flavor of the api's, but look at the api's themselves to make sure that you have the linkage right for the current version of lwIP. I think that you will find one of these api's to be what you need.
Scott Taggart wrote:
|[Prev in Thread]||Current Thread||[Next in Thread]|