This reminds me a lot of the processor communication content from CS110, where we learned about the waitpid function and the appropriate flags of WNOHANG, WUNTRACED, and others (depending on if whether or not we wanted to block while the child process was completing). Additionally, it helped me to think about this in the contexts of piping, which also facilitates communication between processes.

How does this work exactly? Like, does the receiving function not depend on the data received? What work can it really do while the data has not been updated, such as in the previous grid example we've been using?

@huangda The receiving function still depends on the data, but the application architecture changes to account for the fact that messages can arrive at any time. This requires some mechanism other than waiting for a function call to return. The main change is that the application no longer controls when network events occur/are handled.

Two examples of mechanisms to facilitate async IO are callbacks and event queues. With callbacks, the application provides the networking layer, or whatever is below it in the software stack, a function to run when a message is sent or arrives. With an event queue, you might set up several threads to poll on a shared queue-- the queue is usually some other API exposed by the OS or your IO library. When there are no messages, no callbacks are run, or in the case of an event queue, the threads will block while trying to take the next event from the queue.

As for what work can be done while data has not been updated, this is a similar situation to the homework assignments in which it is better to think about the steady state when the application has been running for a while and many messages are being sent and received. Callbacks will run back-to-back, and threads will be busy pulling events from a filled queue. What distinguishes async IO, in this case, is that the time you would spend waiting for network transactions to complete is instead spent processing more data.

How does this work on a hardware level? If messages can arrive at any time, how does the messaging library know it needs to copy the data into 'bar' and how does your aforementioned callbacks know to be called? It seems like some sort of interrupt must occur intuitively. A follow up to this question is what would be the computation overhead of doing these interrupts/context switches?

I've worked with Javascript async before where theres usually a callback function or a wait function that doesnt execute until the async has returned (Promises). is that akin to what we see here with Checkrecv and checksend? in that they pause execution until the check is properly sent/received?