|
| From: | geckook Xu |
| Subject: | Re: [lwip-devel] Re: [lwip-users] MEMP_TCP_SEG somehow being leaked so that they never become available for reuse. |
| Date: | Fri, 23 Mar 2007 23:31:24 +0800 |
The tcp_close and tcp_abort are called in callback function of tcp_recv and tcp_poll, and callback functions are called by lwip stack thread, so I think they are runing in the same thread. If not, What's thread they belong to? I use the raw api to create a listen server ,and make a client function for connecting to the other station. the listener and the client used the same tcp callback functions except the tcp_accept() and tcp_connected() callback functions. When I create a listen tcp_pcb and in the same time I user the client function to creae a connection to the other station , in this case, are they in the same thread ? (raw api use the callback functions to call them which is called by lwip stack thread, so I think the listener and client is in the same thread that lwip stack thread) what should I do so that to control the synchronization between my time functions and the lwip stack thread? there are my code: http://lists.gnu.org/archive/html/lwip-users/2007-03/msg00123.html can you look into it and give me some idea? On 3/22/07, Kieran Mansley <address@hidden> wrote:
On Thu, 2007-03-22 at 22:29 +0800, geckook Xu wrote: > I have set TCP_PCB to 1000, TCP_SEG to 600, TCP_MSG to 8, > When I make a lot of connections to the server, the server's lwip > stack MEMP_TCP_SEG will be leaked. > if I add lock in my time functions where I call tcp_close or > tcp_abort, then the MEMP_TCP_SEG will be released well, but in this > case , MEMP_TCP_SEG will be released slowly than before and slow than > TCP_PCB be released. > > If I set TCP_MSG 50, when more than 8 have been used, TCP_MSG will be > leaked ( in this case, I didn't add lock in tcp_close and tcp_abort ). > > What is the metter. and What should I do? As I said before: make sure that your timer functions and other threads are not running at the same time in the lwIP code! Only one thread at once should be allowed. It's not sufficient to just protect tcp_close or tcp_abort with locks. You have to protect *everything*. Kieran _______________________________________________ lwip-devel mailing list address@hidden http://lists.nongnu.org/mailman/listinfo/lwip-devel
| [Prev in Thread] | Current Thread | [Next in Thread] |