[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-devel] [bug #21356] client thread freezes after MEMP_TCPIP_MSG sta
From: |
Frédéric Bernon |
Subject: |
[lwip-devel] [bug #21356] client thread freezes after MEMP_TCPIP_MSG starvation |
Date: |
Wed, 17 Oct 2007 20:42:00 +0000 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 |
Update of bug #21356 (project lwip):
Status: None => Duplicate
Open/Closed: Open => Closed
_______________________________________________________
Follow-up Comment #3:
>TCPIP msg is taken from the stack. I don't understand how another thread
might asynchronously retrieve valid memory from this stack ? Isn't this fix
dangerous ?
It's not asynchronsly, since the "netconn side" thread always wait that
tcpip_thread end the action before return, so, this is not dangerous. Since
the change was done there is several months, I think we can consider that as
stable. There is in the CVS HEAD lot of change to fix several lot of problems
with sequential api. Now, I think we can tell it's really more stable than
1.2.0. So, I suggest you to upgrade your port to HEAD code. You can find some
informations here :
http://lwip.scribblewiki.com/LwIP_version_1.3.0_release_notes
Note this particular point around your problem: "New MEMP_NUM_TCPIP_MSG_API
and MEMP_NUM_TCPIP_MSG_INPKT replace older MEMP_NUM_TCPIP_MSG."
>As a consequence sys_mbox_post may fail.
lwIP sequential API is (and was) design on the fact that "sys_mbox_post"
should never failed. So, you should change your sys_arch to avoid this
case...
I close this record, but if you have some others questions, please, feel free
to send it (if they are on HEAD code, perhaps "lwip-devel" mailing list is
better than the bugtracker).
_______________________________________________________
Reply to this item at:
<http://savannah.nongnu.org/bugs/?21356>
_______________________________________________
Message posté via/par Savannah
http://savannah.nongnu.org/