4 ms·

I'm awaiting for the promise of the function I'm calling to resolve, similar to what I do in an async function. Why is there nothing to wait for? Actually I do

I'm awaiting for the promise of the function I'm calling to resolve, similar to what I do in an async function. Why is there nothing to wait for? Actually I don't understand why the `async` keyword is needed at all.

dbbk 5y ago
If you're waiting, it's not synchronous by definition. It's already an asynchronous function.
- toast0 5y ago
  This is kind of turning the classical definitions on their head. Synchronous I/O functions don't rerurn until the I/O is complete (or complete enough, anyway). The calling function effectively waits for completion. Asynchronous I/O functions return right away, but completion is signaled elsewhere. The calling function does not have to wait (but it can choose to wait for completion if necessary). Asynchronous messaging may not even provide a completion signal, if you want to know it got there, the other side needs to send an asynchronous message back to confirm. Await/async is confusing enough without redefining terms to mean their opposites.
  - endorphine 5y ago
    Yes, exactly what I was thinking. I think that I was confused in the first place because `await` I thought meant "block until this function returns". Whereas it really means: "don't wait, swap me out".
    - toast0 5y ago
      Yeah, I think a lot of that is the interface isn't great/the abstraction is leaky and you need to know a lot about the details. Because implementations of async/await seem to usually rely on some sort of thread sharing, await also implies yield, and there's often no or limited preemption. Of course, in Javascript, you don't usually have multiple threads at all (unless you fit into one of the special exemptions that allow multiple threads), so your options are pretty limited.
tangent128 5y ago
If you want your function to block until the promise resolves, then the function calling it also has to block, and the function calling that has to block, and so forth. At the top of the chain, this ultimately blocks the entire event loop (Javascript semantics are generally not concurrent), so no UI/network events can be processed until that promise resolves and the page/server is left non-responsive. (And that's assuming you can somehow define clear semantics to run any Javascript code involved in resolving the promise; otherwise, you're deadlocked!)
roywiggins 5y ago
If you have one thread, and it's just in a loop checking and rechecking on a promise to resolve, you will deadlock, because nothing is actually running the async function. Await actually pauses your function and allows the async runtime to work on other stuff, such as completing the function you just awaited on.
gpderetta 5y ago
At least in python it is needed so that the interpreter can issue very cryptic syntax errors. No, I'm not bitter.
bmn__ 5y ago
> Actually I don't understand why the `async` keyword is needed at all. Indeed: $ raku -e'sub non-async { await start { say "hello world" } }; non-async' hello world

dbbk 5y ago

If you're waiting, it's not synchronous by definition. It's already an asynchronous function.

toast0 5y ago
This is kind of turning the classical definitions on their head. Synchronous I/O functions don't rerurn until the I/O is complete (or complete enough, anyway). The calling function effectively waits for completion. Asynchronous I/O functions return right away, but completion is signaled elsewhere. The calling function does not have to wait (but it can choose to wait for completion if necessary). Asynchronous messaging may not even provide a completion signal, if you want to know it got there, the other side needs to send an asynchronous message back to confirm. Await/async is confusing enough without redefining terms to mean their opposites.
- endorphine 5y ago
  Yes, exactly what I was thinking. I think that I was confused in the first place because `await` I thought meant "block until this function returns". Whereas it really means: "don't wait, swap me out".
  - toast0 5y ago
    Yeah, I think a lot of that is the interface isn't great/the abstraction is leaky and you need to know a lot about the details. Because implementations of async/await seem to usually rely on some sort of thread sharing, await also implies yield, and there's often no or limited preemption. Of course, in Javascript, you don't usually have multiple threads at all (unless you fit into one of the special exemptions that allow multiple threads), so your options are pretty limited.

tangent128 5y ago

If you want your function to block until the promise resolves, then the function calling it also has to block, and the function calling that has to block, and so forth. At the top of the chain, this ultimately blocks the entire event loop (Javascript semantics are generally not concurrent), so no UI/network events can be processed until that promise resolves and the page/server is left non-responsive. (And that's assuming you can somehow define clear semantics to run any Javascript code involved in resolving the promise; otherwise, you're deadlocked!)

roywiggins 5y ago

If you have one thread, and it's just in a loop checking and rechecking on a promise to resolve, you will deadlock, because nothing is actually running the async function. Await actually pauses your function and allows the async runtime to work on other stuff, such as completing the function you just awaited on.

gpderetta 5y ago

At least in python it is needed so that the interpreter can issue very cryptic syntax errors. No, I'm not bitter.

bmn__ 5y ago

> Actually I don't understand why the `async` keyword is needed at all. Indeed: $ raku -e'sub non-async { await start { say "hello world" } }; non-async' hello world