[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-devel] [task #7865] implement non-blocking SEND operation (socket)
From: |
Jonathan Larmour |
Subject: |
[lwip-devel] [task #7865] implement non-blocking SEND operation (socket) |
Date: |
Thu, 20 Mar 2008 14:54:31 +0000 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.12) Gecko/20070530 Fedora/1.5.0.12-1.fc5 Firefox/1.5.0.12 |
Follow-up Comment #2, task #7865 (project lwip):
Jim Pettinato wrote:
> Do you really need to implement another queue, or could you just
> have it return an error eg ERR_WOULD_BLOCK if there is no longer
> room on the existing TCP send queue, and let the task retry
> later?
Well that's a tricky thing I should probably have highlighted. A full send
queue is not the only thing that can cause tcp_enqueue to return ERR_MEM. It
can also happen if you run out of MEMP_TCP_SEGs, pbufs of the needed sort,
having a resulting tcp queue which ends up too long once this write is added,
and more. Have a look.
Superficially you might think that that's ok if you just try the tcp_write
and look for ERR_MEM, but how does an application then know when more
resources become available? ie. an app waiting in lwip_select() has to be
blocked (so tcp_write returning ERR_MEM would imply :
API_EVENT(conn, NETCONN_EVT_SENDMINUS, len);
So what would be calling:
API_EVENT(conn, NETCONN_EVT_SENDPLUS, len);
in that case since the lack of resource may be unconnected to the send data
enqueued for this tcp pcb.
_______________________________________________________
Reply to this item at:
<http://savannah.nongnu.org/task/?7865>
_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/