|Subject:||Re: [lwip-users] Re: PBUF Leak Problems...|
|Date:||Fri, 21 Sep 2007 14:33:58 +0200|
Sorry, I don't have yet all the thread (I will do).
But, if I remember, we have already talk about that in a previous one. The main problem is the current tcpip.c design is done on the idea the sys_mbox_post never block or never failed:
- if it block, tcpip.c can't process other messages (input packets, api calls, etc..), and you can even have some deadlocking case (an application which doesn't read its recvmbox, this last become full, tcpip is blocked to post a new pbuf to this recvmbox, and if the application which should read do before a "write/sendto", since tcpip wait recvmbox is fetch, and since app wait to write before read, you got a deadlocking). The "solution" is to have a mailbox size > your number of pbufs (like this, you drop input packets, what is better support by lwIP current code), or to reduce your TCP_WND.
- if it failed, we have to process lot of cases with retry, or "undo", etc... By example, if in accept_function in api_msg.c, sys_mbox_post failed, we have to "undo" all stuff for the newconn allocated, or do a retry, with some temporary lists, etc... which give lot of code to add (not really "lightweight").
----- Original Message -----
|[Prev in Thread]||Current Thread||[Next in Thread]|