You Keep Using That Word: Asynchronous and Interprocess Comms | Hacker News Reader

You Keep Using That Word: Asynchronous and Interprocess Comms

youtube.com

34 pointsself14 comments

I loved the tone suggestion. I definitely took the title as a "correction of people using the term wrong," but that is not the push here. Fun watch.

I do find a lot of the concepts that go into this rather interesting to look at in the small. Specifically, I don't think you have to squint hard to see a pipelined processor as using a lot of these same tricks to get things faster. Add in some of the data flow and you are able to see the processor as its own broker for data between instructions it has been given.

How does hn define sync/async comms?

Me personally I think it has a lot to do with attention, at the risk of abusing a buzz word in vogue since the dawn of the transformer. But as long as attention must be continuous somewhere in your system, you have sync comm. When you can decide when to give attention to something, making attention brittle, you have async.

I can't speak for all of HN, but I can speak for me.

I maintain a library for a language that does network comms.

All the calls are simply passed to another background thread, and the code in the calling thread keeps going. In other words all the commands are non blocking.

That's for outgoing. For incoming a message is sent to the originating thread (actually to the originating object on the originating thread) and the object can the process the incoming at their convenience.

For me this is async. The request and the response are disconnected in the running code. You might request here, but the response appears over there.

It's easier to understand on the server side. There the object is just chilling, and suddenly a message arrives out of nowhere to alert to an incoming packet.

Sync comms "blocks" the program until the reply arrives. This could take milliseconds, or minutes, depending on what you are asking for. Which means your program is unresponsive in this time.

I think if we want to use language we should know what we are talking about. I understand his point to be: people have differing opinions of what asynchronous communication (back in the day it was called asynchronous I/O) means, so let's not use the word at all. Instead just describe what you are doing which more words, which are needed anyway and drop the word asynchronous.

I think it is a good idea to give this topic some attention, but I think it is defeatist to conclude that the word is doomed to be useless.

I don't think the communication protocol between two processes, services, whatever has have the property of being synchronous or asynchronous.

It is more about how each side of the communication handles it internally. Synchronous means I shoot off the message, wait until it is processed and I got a response (in case there is supposed to be a response), doing nothing else in the meantime and only after everything is done continue with the next thing I need to do. Asynchronous means I continue doing any type of work in the meantime while the message is sent and processed. That usually means anything that doesn't depend on the response.

Note that my communication partner will usually not care/notice if I am doing anything else in the meantime. I am saying usually because he might notice if I continue sending the same communication partner additional messages before I got a response.

Now the reason why we talk about synchronous and asynchronous communication when communicating between people is that some like to invoke a false equivalence. In the person-to-person communication it is fair to say a phone call, meeting, etc. are methods of synchronous communication and email asynchronous communication. This is more a social thing and has to do with the expectation of time for the response. When I speak on the phone, the receiver has to listen, process and understand exactly at the time I am speaking, i.e. synchronously. That need arises from my social expectation that the person is able to respond in some form seconds later (as opposed to hours or days for something like email). It should be clear here that the terms are used in a different sense as also mentioned in the talk, this is about context, which is also clear in the twitter responses he got. We sometimes have arguments when to prefer one over the other in person-to-person cummincation, and then sometimes this false equivalence with sync/async I/O is invoked.

[I haven't watched the video - I come to HN to read .. but that said]

> I don't think the communication protocol between two processes, services, whatever has have the property of being synchronous or asynchronous.

This is news to those of us who have implemented or designed communication protocols between processes.

> It is more about how each side of the communication handles it internally.

You are confusing processing of information obtained via communication with the pattern of communication. A synchronous protocol is a lock-step exchange of data/meta-data between two communicating processes. You can have processes communicating via a synchronous protocol that handle the processing in an asynchronous manner. An asynchronous protocol does not require exchange of messages to be lock-step

   A: HELO w/ MY CREDS <blocks>
   B: HELO - ACCEPT CREDS
   A: GET 'foo' <blocks>
   B: HERE is 'foo' <data> 
   [A: queue foo data for async processing by an internal comp A']
   A: GET 'bar' <blocks>
   [A': processed 'foo'] 
   B: HERE is 'bar' <data> 
   [A: queue bar data for async processing by an internal comp A']
   ...
   [A': processed 'bar']

and then there could be this:

   A: HELO w/ MY CREDS <blocks>
   B: HELO - ACCEPT CREDS  
   A: GET 'foo' <doesn't block>
   A: GET 'bar' <doesn't block>
   B: HERE is 'foo' <data>       # B may even return 'bar' first in some cases 
   [A: queue foo data for processing ...]
   A: GET 'foobar' <doesn't block>
   B: HERE is 'bar' <data> 
   [A: queue bar data for processing]
   ...
   B: HERE is 'foobar' <data> 
   ...

Quaint diagrams we used to draw for protocols - this is just some random example from a quick search [note how it transitions from a sync handshake to async comm]:

https://www.researchgate.net/publication/344006359/figure/fi...

What I think GP meant is that [a]synchrony is a property of how one locally handles the need to "wait" for something, and if the protocols being spoken are do not impose order then this is really evident. E.g.,

  A: do thing #0 (no wait)
  A: do thing #1 (no wait)
  A: do thing #2 (no wait)
  B: thing #1 result
  A: do thing #3 (no wait)
  B: thing #0 result
  B: thing #3 result
  A: do thing #4 (no wait)
  B: thing #2 result
  B: thing #4 result

In this example A reads responses from B but never sits idle while "waiting" for those responses.

At some point A might need to "block" waiting for all the results for extant requests. What does "block" mean? It could mean: not sending any more requests, not allowing the user to initiate more requests, not being responsive in the UI, and probably more.

A could also speak the same protocol synchronously:

  A: do thing #0
  A: <wait>
  B: thing #0 result
  A: do thing #1
  A: <wait>
  ...

Assuming this protocol does not impose ordering, then, the [a]synchrony property is purely local to A.

Even if order is required, A might do other things "while waiting" for responses from B, and that... might be asynchrony. In the traditional Unix single-threaded process model A might block but the system continues to be responsive because the kernel is not synchronous even if A is, and so the kernel can schedule other processes while A "waits" -- but no one would say that A is async in that case, nor would anyone say that the whole system is async either unless A's functionality were spread over multiple processes in such a way that the UI (or whatever) has an "async feel".

In reality we might have blocking behaviors even in fully async cases like the first one above owing to flow control, but even there the meaning of "blocking" will depend on what A does when B can't receive more messages due to flow control: A could transmit backpressure to whatever is causing A to generate messages to B, or A could stop generating messages to B, or A could stop being responsive in its UI, or...

I believe this is what TFA was getting at: that the meanings of these words (blocking, waiting, asynchronous, etc.) are somewhat fuzzy. Still, when someone says "let's do this asynchronously" I know what they mean, at least for the purposes of the discussion in which it comes up -- in actual design and implementation, once again, the meaning may vary, but the intent is still the same! The intent of doing things asynchronously is to amortize latency and better utilize local resources.

I believe what you describe is called pipelining.

I think it's all a bit "in the eye of the beholder" as far as protocols. Here I mean the message patterns and implicit state models, ignoring software design choices.

I'd say the IP protocol is asynchronous in terms of flinging individual packets around. They can be buffered, delayed, etc. They can arrive at the recipient without notice.

TCP starts to make it "more synchronous" since the two parties have to signal back and forth negotiate coordinated buffers and perform a sequence of steps within timeout deadlines.

SMTP seems more asynchronous in terms of whole messages being delivered and stored without protocol-level coordination between messages.

Non-pipelined HTTP 1.1 is both "more synchronous" and "less synchronous". It adds more timing behavior to the use of TCP to have simplex phases of client-sending and server-sending. At the same time, you can think of the request and response messages a bit like email messages to be stored and forwarded. But there are narrower response time limits for an HTTP message pair to succeed or fail at the transport level compared to a message and reply via email.

Of course, these different scenarios are happening all at once in a normal SMTP or HTTP exchange. So the abstractions layered over introduce new protocol units which may have synchronous or asynchronous characteristics, while the underlying primitives continue to also occur with their own apparent characteristics.

A similar issue exists with voice over IP. The protocol is duplex streams which seems quite asynchronous to me. But a typical conversation involves synchronization at human language boundaries and is quite sensitive to latency. Conference calls can fall apart when participants lose synchronization and start talking over each other. This is a social communication protocol layered over the underlying audio streaming protocol.

Reply on news.ycombinator.com