5 ms·

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 c

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.

eternalban 3y ago
[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/fig1/AS:930766108233728@1598923341044/Diagram-of-communication-protocol.ppm https://www.researchgate.net/publication/344006359/figure/fi...
- cryptonector 3y ago
  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.
- stkdump 3y ago
  I believe what you describe is called pipelining.

eternalban 3y ago

[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/fig1/AS:930766108233728@1598923341044/Diagram-of-communication-protocol.ppm https://www.researchgate.net/publication/344006359/figure/fi...

cryptonector 3y ago
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.
stkdump 3y ago
I believe what you describe is called pipelining.