[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Re: PBUF Leak Problems...

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 -----
Sent: Friday, September 21, 2007 2:11 PM
Subject: [lwip-users] Re: PBUF Leak Problems...

Simon -

I agree, sys_mbox_post should have a return value, does this warrant posting a bug report on it? Sounds we probably should  ...


lwip-users mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]