3 ms·

async isn't only about performance, but has other advantages, like reduced resource consumption. In addition to that async io also gives you better control over

async isn't only about performance, but has other advantages, like reduced resource consumption. In addition to that async io also gives you better control over how to cancel io reads and writes on systems where the IO is not interruptible. But you are correct, if you don't have a specific need, async is generally harder than using threads for concurrency. Ideally the async/await work in Rust is going to make that trade-off less extreme than it is today, which may mean more people will feel comfortable using it as it should reduce boiler plate.

hobofan 8y ago
> but has other advantages, like reduced resource consumption Could you expand on that? I've never heard that mentioned about async before.
- steveklabnik 8y ago
  You can think of a task as being a thread, but it has one single allocation that’s the exact possible stack size. No more, no less. This uses less memory than spinning up a thread with the default stack size. Yes, you could use the proper APIs and get the correct size too, but you have to figure that size out by hand for each thread. It just implicitly happens with tasks.
  - hobofan 8y ago
    Huh, I didn't know that! (I also misinterpreted the context as I read the top level comment as async vs a single thread with blocking code, but after rereading it that makes more sense.)
    - steveklabnik 8y ago
      It's all good; it's one of the things that's specific to our implementation. Other forms may or may not do this, but I'm pretty sure that it's novel to at least Rust, and maybe C++; there's some discussion that I think it can do this in some circumstances as well.
  - arve0 8y ago
    Default stack size for new threads is 2 MB, https://doc.rust-lang.org/std/thread/#stack-size https://doc.rust-lang.org/std/thread/#stack-size. That means total_memory_usage = 2 MB * number_of_cores, which is not so much on modern hardware.
    - arve0 8y ago
      ...and of course you know that, being on the Rust core team, just adding the specifics (I did not know the numbers myself).
      - steveklabnik 8y ago
        Hm, maybe I misunderstand what you're getting at; you're talking about one thread per core, not one thread per unit of work? Sure, if you only have that few threads, then it's not that big of a difference, but if you want to spin up a few hundred thousand of them...
        arve0 8y ago
        > you're talking about one thread per core, not one thread per unit of work? Yes, a thread pool, consisting of one thread per core/computing unit. The units of work are then scheduled between the threads. Units of work here being some kind of IO, e.g. servicing HTTP requests. > but if you want to spin up a few hundred thousand of them... Hm. Thought there was a limit for work that can be done concurrently by the CPU, based on the number of cores/hyper-threads available. Found this on threads and IO performance [1], it seems to make the same point. What kind of work load is common to spread over so many threads (on the same machine)? Does the OS switch efficiently between hundred of threads on regular CPUs? Genuinely interested. 1: https://www.jstorimer.com/blogs/workingwithcode/7970125-how-many-threads-is-too-many https://www.jstorimer.com/blogs/workingwithcode/7970125-how-...
        steveklabnik 8y ago
        Yeah okay. That’s a way to do things too, of course. I have some stuff to say but I’m about to go get some dinner, I’ll reply for real later. (And I’m sure others in this thread have opinions too)
- Tarean 8y ago
  A fun example is the slow loris attack. You send your requests character by character with 20+ seconds between packets. For mobile 20 seconds can happen so if the server doesn't use a running window to check timeouts it can't kill the connection. Now you do this 1000 times you use barely any resources but the server uses 1GB in stack allocations which might be the maximum and noone else can connect. https://en.wikipedia.org/wiki/Slowloris_(computer_security) https://en.wikipedia.org/wiki/Slowloris_(computer_security)

hobofan 8y ago

> but has other advantages, like reduced resource consumption Could you expand on that? I've never heard that mentioned about async before.

steveklabnik 8y ago
You can think of a task as being a thread, but it has one single allocation that’s the exact possible stack size. No more, no less. This uses less memory than spinning up a thread with the default stack size. Yes, you could use the proper APIs and get the correct size too, but you have to figure that size out by hand for each thread. It just implicitly happens with tasks.
- hobofan 8y ago
  Huh, I didn't know that! (I also misinterpreted the context as I read the top level comment as async vs a single thread with blocking code, but after rereading it that makes more sense.)
  - steveklabnik 8y ago
    It's all good; it's one of the things that's specific to our implementation. Other forms may or may not do this, but I'm pretty sure that it's novel to at least Rust, and maybe C++; there's some discussion that I think it can do this in some circumstances as well.
- arve0 8y ago
  Default stack size for new threads is 2 MB, https://doc.rust-lang.org/std/thread/#stack-size https://doc.rust-lang.org/std/thread/#stack-size. That means total_memory_usage = 2 MB * number_of_cores, which is not so much on modern hardware.
  - arve0 8y ago
    ...and of course you know that, being on the Rust core team, just adding the specifics (I did not know the numbers myself).
    - steveklabnik 8y ago
      Hm, maybe I misunderstand what you're getting at; you're talking about one thread per core, not one thread per unit of work? Sure, if you only have that few threads, then it's not that big of a difference, but if you want to spin up a few hundred thousand of them...
      - arve0 8y ago
        > you're talking about one thread per core, not one thread per unit of work? Yes, a thread pool, consisting of one thread per core/computing unit. The units of work are then scheduled between the threads. Units of work here being some kind of IO, e.g. servicing HTTP requests. > but if you want to spin up a few hundred thousand of them... Hm. Thought there was a limit for work that can be done concurrently by the CPU, based on the number of cores/hyper-threads available. Found this on threads and IO performance [1], it seems to make the same point. What kind of work load is common to spread over so many threads (on the same machine)? Does the OS switch efficiently between hundred of threads on regular CPUs? Genuinely interested. 1: https://www.jstorimer.com/blogs/workingwithcode/7970125-how-many-threads-is-too-many https://www.jstorimer.com/blogs/workingwithcode/7970125-how-...
        steveklabnik 8y ago
        Yeah okay. That’s a way to do things too, of course. I have some stuff to say but I’m about to go get some dinner, I’ll reply for real later. (And I’m sure others in this thread have opinions too)
Tarean 8y ago
A fun example is the slow loris attack. You send your requests character by character with 20+ seconds between packets. For mobile 20 seconds can happen so if the server doesn't use a running window to check timeouts it can't kill the connection. Now you do this 1000 times you use barely any resources but the server uses 1GB in stack allocations which might be the maximum and noone else can connect. https://en.wikipedia.org/wiki/Slowloris_(computer_security) https://en.wikipedia.org/wiki/Slowloris_(computer_security)