4 ms·

What's the advantage of async if you immediately call await?

by doakes 3y ago

maleldil 3y ago
From the library perspective, they're yielding control to the runtime. This means the user can do whatever they want with the future.
sodality2 3y ago
If you're I/O bound, it allows for easy and efficient utilization of resources by enabling other tasks to run while waiting for I/O. I'll give you a real world example. I wrote some code that listened to a websockets URL from thousands of Reddit posts - specifically, the one that sends new messages on new comments - so I could see a stream of Reddit comments for any given sub. Implemented it using Tungstenite (synchronous) and it created thousands of threads to listen, and used enormous chunks of memory (several GB) for the stack space + memory reading for every single WS stream. Implemented it using Tokio_tungstenite, the async alternative, and it used a handful of MB of memory and barely any CPU to listen to thousands of WS servers.
- doakes 3y ago
  But at what point are you calling await? If I were using the author's library, I would call `.some_endpoint(...)` and that would return a `SpotifyResult<String>`, so I'm struggling to understand why `some_endpoint` is async. I could see if two different threads were calling `some_endpoint` then awaiting would allow them to both use resources, but if you're running two threads, doesn't that already accomplish the same thing? I'm pretty naive to concurrency.
  - sodality2 3y ago
    I was calling await on ws_stream.next() - awaiting for there to be a new message. Code: https://gist.github.com/sigaloid/d0e2a7eb42fed8c2397fbf8423999035 https://gist.github.com/sigaloid/d0e2a7eb42fed8c2397fbf84239... In the example you give, yes, it's just sequential and everything relies on a previous thing. But say you are making a spotify frontend - you want to render a list of playlists, the profile info, etc - you call await on all of them and they can complete simultaneously.
  - deleted 3y ago
    [deleted]
  - roywiggins 3y ago
    If you are only ever doing one thing at a time, then async doesn't do you any good, which is why people like to use sync libraries when they can't make use of it, and why libraries might want to provide a sync and an async version. Async is useful when you want to have a bunch of things happening (approximately) "at the same time" on a single thread. With async you can await on two different SpotifyResults at the same time without multithreading. When each one is ready, the runtime will execute the remainder of the function that was awaiting. This means the actual HTTP requests can be in flight at the same time.
    - doakes 3y ago
      I guess I'm just confused that it's labeled async (and does async work) but is actually blocking when invoked (or at least doesn't return until await finishes). If I'm awaiting on two different results, I have to invoke them in parallel somehow, right? What is that mechanism and why doesn't that already provide asynchrony? Like, if the method was sync, couldn't I still run it async somehow?
      - mplanchard 3y ago
        This is sort of the core of the whole idea of concurrency. There are lots of good explanations online if you search for “concurrency vs parallelism.” The gist is that while you await the result of an async function, you yield to the executor, which is then free to work on other tasks until whatever the await is waiting for has completed. The group of tasks being managed by the executor is all different async functions, which all yield to the executor at various times when they are waiting for some external resource in order to make forward progress, to allow others to make progress in the meantime. This is why people say it’s good for IO-bound workloads, which spend the majority of their time waiting for external systems (the disk, the network, etc)
      - Too 3y ago
        You might be awaiting for only one result, but the one calling you may be awaiting both you and 100 other things that you are not aware of.
      - 3y ago
  - fshbbdssbbgdd 3y ago
    A common usecase for async is if you are implementing a web service with an API. Suppose your API uses Spotify’s API. Your server can handle many requests at once. It would be nice if all of them can call Spotify’s API at the same time without each holding a thread. Tokio tasks have much lower overhead than OS threads. Your N requests can all await at once and it doesn’t take N threads to do it.
empath-nirvana 3y ago
If you're not using multiple tasks, there's no advantage. If you are running multiple tasks, it passes control back to the executor.

What's the advantage of async if you immediately call await?

by doakes 3y ago

What's the advantage of async if you immediately call await?

From the library perspective, they're yielding control to the runtime. This means the user can do whatever they want with the future.

sodality2 3y ago

If you're I/O bound, it allows for easy and efficient utilization of resources by enabling other tasks to run while waiting for I/O. I'll give you a real world example. I wrote some code that listened to a websockets URL from thousands of Reddit posts - specifically, the one that sends new messages on new comments - so I could see a stream of Reddit comments for any given sub. Implemented it using Tungstenite (synchronous) and it created thousands of threads to listen, and used enormous chunks of memory (several GB) for the stack space + memory reading for every single WS stream. Implemented it using Tokio_tungstenite, the async alternative, and it used a handful of MB of memory and barely any CPU to listen to thousands of WS servers.

doakes 3y ago
But at what point are you calling await? If I were using the author's library, I would call `.some_endpoint(...)` and that would return a `SpotifyResult<String>`, so I'm struggling to understand why `some_endpoint` is async. I could see if two different threads were calling `some_endpoint` then awaiting would allow them to both use resources, but if you're running two threads, doesn't that already accomplish the same thing? I'm pretty naive to concurrency.
- sodality2 3y ago
  I was calling await on ws_stream.next() - awaiting for there to be a new message. Code: https://gist.github.com/sigaloid/d0e2a7eb42fed8c2397fbf8423999035 https://gist.github.com/sigaloid/d0e2a7eb42fed8c2397fbf84239... In the example you give, yes, it's just sequential and everything relies on a previous thing. But say you are making a spotify frontend - you want to render a list of playlists, the profile info, etc - you call await on all of them and they can complete simultaneously.
- deleted 3y ago
  [deleted]
- roywiggins 3y ago
  If you are only ever doing one thing at a time, then async doesn't do you any good, which is why people like to use sync libraries when they can't make use of it, and why libraries might want to provide a sync and an async version. Async is useful when you want to have a bunch of things happening (approximately) "at the same time" on a single thread. With async you can await on two different SpotifyResults at the same time without multithreading. When each one is ready, the runtime will execute the remainder of the function that was awaiting. This means the actual HTTP requests can be in flight at the same time.
  - doakes 3y ago
    I guess I'm just confused that it's labeled async (and does async work) but is actually blocking when invoked (or at least doesn't return until await finishes). If I'm awaiting on two different results, I have to invoke them in parallel somehow, right? What is that mechanism and why doesn't that already provide asynchrony? Like, if the method was sync, couldn't I still run it async somehow?
    - mplanchard 3y ago
      This is sort of the core of the whole idea of concurrency. There are lots of good explanations online if you search for “concurrency vs parallelism.” The gist is that while you await the result of an async function, you yield to the executor, which is then free to work on other tasks until whatever the await is waiting for has completed. The group of tasks being managed by the executor is all different async functions, which all yield to the executor at various times when they are waiting for some external resource in order to make forward progress, to allow others to make progress in the meantime. This is why people say it’s good for IO-bound workloads, which spend the majority of their time waiting for external systems (the disk, the network, etc)
    - Too 3y ago
      You might be awaiting for only one result, but the one calling you may be awaiting both you and 100 other things that you are not aware of.
    - 3y ago
- fshbbdssbbgdd 3y ago
  A common usecase for async is if you are implementing a web service with an API. Suppose your API uses Spotify’s API. Your server can handle many requests at once. It would be nice if all of them can call Spotify’s API at the same time without each holding a thread. Tokio tasks have much lower overhead than OS threads. Your N requests can all await at once and it doesn’t take N threads to do it.

empath-nirvana 3y ago

If you're not using multiple tasks, there's no advantage. If you are running multiple tasks, it passes control back to the executor.