[63stack]

Another thing is that the article emphasized that it's single threaded. That by itself guarantees that there will only ever be 1 inflight request, since calling the send() function will block until the request completes, and the callback is called.

If there is some kind of cooperative multitasking going on, then it should be noted in the pseudo code with eg. async/await or equivalent keywords. As the code is, send() never gives back control to the calling code, until it completely finishes.

[_benton]

JS has an event loop, it's single threaded but still lets you write asynchronous code.

let send = (payload, callback) => fetch(...).then(callback)

fetch() returns a promise synchronously, but it's not awaited.

[63stack]

I'm well aware, but the send() function in the article is not marked as async, and has no .then() calls.

[gpderetta]

it is too abstract to say for sure, but send might just block until the request is handled off to the next layer (for example succesfully written to the OS network socket buffer), so unless the server carefully closes its recv window until it is done handling the request[1] , no, I wouldn't expect send to block until the server is done handling the request.

[1] i.e. backpressure, which would actually be the ideal way for the server to implement whatever rate limiting it wants, but we are assuming here that the server has a less than ideal interface.

[rehevkor5]

Yeah that confused me at first too. They seem to be treating send() as if it has the same behavior as a setTimeout() call. If you think of it that way, it starts to make sense.