|
| From: | Frédéric BERNON |
| 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] |