In the non-blocking cases, how can we make sure that the total amount of data stored in the network buffer will always be smaller than the capability of the buffer? (if the thread is going to stop and wait until there are available space in the buffer for this thread to call send?)

The non-blocking asynchronous send/recv will hide the latency of waiting for a response.

Similar question -- what happens if a thread who asked to receive some info tries to act on it immediately -- will it be switched off the processor until its CHECKRECV() marks true?

@trip Yes, my understanding is that all this is really doing is delaying the blocking behavior into a different set of function calls (from send/recv to checksend/checkrecv) meaning that a thread asks to receive some information via recv() and then immediately tries to use that information (which requires a checkrecv() call to ensure the existence of the data it wants to operate on), it will then just be blocked until the checkrecv() call clears and marks the thread as able to proceed.

@nickbowman "delaying the blocking behavior into a different set of function calls" makes sense. To rephrase, this is still a "blocking" statement but divided into two parts, which allows other things to happen in the middle, thus preventing deadlock.

@assignment7 I think this depends on the implementation. For example, the underlying process that handles message sending may receive response from the receiving end and determine if it need to resend the message.

Yes, it depends on the implementation details. The messages are usually broke into small chunks/packets and the sender could continuously write/overwrite to the receiver's buffer (like a pipe) until the CHECKRECV() returns true.