Re: [lwip-users] critical section protection + timer issues

[Jim Gibbons]

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:

OK, Based on what both Jim and Adam says there is still something I obviously have no clue on.  Perhaps it’s because I am not calling into the LWIP stack properly that is leading to my confusion.  I will start by asking a “stupid” question – perhaps the answer will tell me why I am so confused on this thread-timer-blocking issue…

My question is: suppose I have an arbitrary thread that wants to establish a TCP connection and transfer data.  Should this thread call tcp_connect, tcp_write, etc.?  Or should it call a different level interface (perhaps use the mailbox that tcpip_thread processes)?  I ask this because if the answer is: it should call tcp_connect, et. al., then I see no possible way for this thread to not also call one of the three sys.c “blocking” functions in order for the LWIP timer logic to work.  Here’s my reasoning:

Thread 1 calls tcp_connect which results in a timer entry being created for THAT THREAD ONLY.

Now, until that same thread blocks on one of the three LWIP sys.c calls (sys_mbox_fetch(), etc.) then that timer for that tcp_connect will never fire.

I have seen various contradictions to this in the responses.  Adam’s response also implies this is not true.  The only way I can see this not true is that threads never call the raw interface but instead always go through the mailbox interface that tcpip_thread processes.  If this is so, then I “get it”.  Did I just misunderstand what interface that a threaded system should use (i.e., a threaded system should use tcpip_thread and its mailbox unless the threads always can block in the sys_mbox_fetch, et. al. calls)?

My apologies for any offense.  I am frustrated with this (my fault) and thought I understood it only to find out quite a bit of work will not work because of that misunderstanding.

Scott

_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users

--

Jim Gibbons	address@hidden
Gibbons and Associates, Inc.	TEL: (408) 984-1441
900 Lafayette, Suite 704, Santa Clara, CA	FAX: (408) 247-6395