You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nuttx.apache.org by GitBox <gi...@apache.org> on 2022/10/11 11:55:24 UTC

[GitHub] [incubator-nuttx] fjpanag commented on pull request #7278: Blocking psock_tcp_recvfrom waits for all requested data.

fjpanag commented on PR #7278:
URL: https://github.com/apache/incubator-nuttx/pull/7278#issuecomment-1274564800

   @xiaoxiang781216 The fact that recv *can* return less bytes than requested, does not mean that it *should*.
   
   At least in my case, all data have been received by the device, in a single TCP frame, but only part of them is in the read-ahead buffer. The data is smaller than the MTU and the available buffers.
   
   > the change may block the recv indefinitely when caller use INFINITE timeout.
   
   This is the expected behavior when you use an infinite timeout, and it is unrelated to the contents of the read-ahead buffer.  
   In fact, if data are unavailable, then surely the code will block (even with the old implementation), since the buffers will also be empty!
   
   The proposed change allows the user to fine-tune the socket to their needs, choosing between blocking or non-blocking and selecting a proper timeout. I don't see any problems, or how it can harm existing applications. Quite the contrary, you now have more options.
   
   It also simplifies the user code, as now I have to re-do what the socket does (i.e. loop with `recv()` till all data are received or till timeout). 
   
   Do you see any problems / disadvantages with this PR?
   
   
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org