lwip-devel
[Top][All Lists]
Advanced

[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/





reply via email to

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