5 ms·

Not true. The await statement will kick the operation over to the event loop to wait for a response, and the thread itself will keep humming along (pulling othe

Not true. The await statement will kick the operation over to the event loop to wait for a response, and the thread itself will keep humming along (pulling other events off the loop, handling animations and scrolling, etc)

TeMPOraL 3y ago
Not on await, no, unless the caller/awaiter is async too?
- brundolf 3y ago
  The function containing the `await` waits, but the thread does not; it switches to doing other things: - Page scrolling/rendering - If the user triggers an event, like clicking on a button, that JS event handler is independent from the waiting function and can run while it's waiting - Same thing if some other `await`ed IO resolves; that function can resume while the other one is still waiting This is why async/await exists. It allows our code to tell the runtime "let me know when this is ready, otherwise do whatever you want in the meantime". Many languages have a similar feature now, but in JavaScript it's especially fundamental to the language and ecosystem, which means code gets written this way by default, which means JS programs don't have the problem mentioned in the OP by default.
  - taeric 3y ago
    I'm curious how this works with event handlers. Suppose you have one on a button that will fetch a number from a server and show it. For fun, assume the server is basically fizzbuzz, but with a 2 second delay for every multiple of 3/5 and a 1 second delay otherwise. If I click the button 4 times quickly (less than a second for all clicks), what happens? I'm assuming it is on the programmer to do some smart debouncing in the event handler?
    - brundolf 3y ago
      Every click will immediately fire a request, and they will come back in whatever order they come back in based on the server's timing (and network latency, and whatever else) Done the straightforward way, you will end up displaying whichever one took the longest to return. I've run into this class of bug before, and since then I make sure to design my primitives to guard against it (always assign the latest-requested instead of latest-received result into state)
      - taeric 3y ago
        Awesome, thanks for confirming my thoughts there. Was hoping to prototype a test soon.
  - TeMPOraL 3y ago
    Okay, I think I am confused about how this works in JS. I've written my fair share of event-driven code, but managed to avoid working with actual async/await. My understanding was that calling an async function does what you describe, but awaiting it literally blocks the caller thread - because what else could it block? Your description sounds like something I'd expect of a yield instruction.
    - brundolf 3y ago
      It blocks the logic flow of the current function, but in a way that can be resumed later If it helps you think about it, any await statement can be converted straightforwardly to an old-fashioned promise resolution with a callback: async function foo1() { doStuff() const res = await doIO() return 'Result: ' + res } function foo2() { doStuff() return doIO().then(res => { return 'Result: ' + res }) }
      - TeMPOraL 3y ago
        That's what I thought. But then, unless foo2() is an async function, the entire thread that's running foo2() will be blocked, will it not?
        brundolf 3y ago
        Nope. It returns a promise, which other logic can then hang a callback off of. But the promise is returned immediately (if just resolves and calls the callback later, like any event listener would)

TeMPOraL 3y ago

Not on await, no, unless the caller/awaiter is async too?

brundolf 3y ago
The function containing the `await` waits, but the thread does not; it switches to doing other things: - Page scrolling/rendering - If the user triggers an event, like clicking on a button, that JS event handler is independent from the waiting function and can run while it's waiting - Same thing if some other `await`ed IO resolves; that function can resume while the other one is still waiting This is why async/await exists. It allows our code to tell the runtime "let me know when this is ready, otherwise do whatever you want in the meantime". Many languages have a similar feature now, but in JavaScript it's especially fundamental to the language and ecosystem, which means code gets written this way by default, which means JS programs don't have the problem mentioned in the OP by default.
- taeric 3y ago
  I'm curious how this works with event handlers. Suppose you have one on a button that will fetch a number from a server and show it. For fun, assume the server is basically fizzbuzz, but with a 2 second delay for every multiple of 3/5 and a 1 second delay otherwise. If I click the button 4 times quickly (less than a second for all clicks), what happens? I'm assuming it is on the programmer to do some smart debouncing in the event handler?
  - brundolf 3y ago
    Every click will immediately fire a request, and they will come back in whatever order they come back in based on the server's timing (and network latency, and whatever else) Done the straightforward way, you will end up displaying whichever one took the longest to return. I've run into this class of bug before, and since then I make sure to design my primitives to guard against it (always assign the latest-requested instead of latest-received result into state)
    - taeric 3y ago
      Awesome, thanks for confirming my thoughts there. Was hoping to prototype a test soon.
- TeMPOraL 3y ago
  Okay, I think I am confused about how this works in JS. I've written my fair share of event-driven code, but managed to avoid working with actual async/await. My understanding was that calling an async function does what you describe, but awaiting it literally blocks the caller thread - because what else could it block? Your description sounds like something I'd expect of a yield instruction.
  - brundolf 3y ago
    It blocks the logic flow of the current function, but in a way that can be resumed later If it helps you think about it, any await statement can be converted straightforwardly to an old-fashioned promise resolution with a callback: async function foo1() { doStuff() const res = await doIO() return 'Result: ' + res } function foo2() { doStuff() return doIO().then(res => { return 'Result: ' + res }) }
    - TeMPOraL 3y ago
      That's what I thought. But then, unless foo2() is an async function, the entire thread that's running foo2() will be blocked, will it not?
      - brundolf 3y ago
        Nope. It returns a promise, which other logic can then hang a callback off of. But the promise is returned immediately (if just resolves and calls the callback later, like any event listener would)