1. 31

  2. 3

    I’ve been enjoying the progress updates on this project! It’s been very helpful in getting into the Rust Async/Await space. Is there a target timeline for this new scheduler to reach stable/master, or would this require async_std v2?

    1. 2

      Before christmas, we usually release on Thursday. From a users perspective, this change is completely transparent.

    2. 2

      This seems too good to be true. What’s the catch? 😉

      1. 1

        As always, there’s still sources of bugs. E.g. block within a task still block the whole task (Joining multiple blocking tasks may be such a thing). You might or might not want this.

      2. 2

        How does it perform when running many blocking tasks block for just barely less than the timeout used for blocking task detection? Does it make execution single-threaded?

        1. 1

          Given that the timeout is adaptive, I consider that unlikely to happen? Machines shut themselves down if there are no tasks available.

          TBH, this is the kind of problem that I would like to see in nature first.

        2. 2

          The new runtime is really fast and outperforms the old one.

          What is “the old one”, in this context?

          1. 3

            A pretty much by-the-numbers work-stealing scheduler with 2*cores threads and a dynamic threadpool on the side to offload blocking tasks (hidden behind the unstable spawn_blocking function).

          2. 2

            The article seems to suggest that spawn_blocking is not needed anymore and/or is a noop with the new runtime? Does that mean that there are cases where the new spawn_blocking causes all futures in a task to block on an operation where it didn’t do so before?


            1. 1

              To answer my own question, spawn_blocking still spawns a new task.

              So, cool, it does not regress and it still makes sense to use around potentially blocking code. If you forget to wrap blocking code, the new runtime will isolate the effects to a single task though AND it is faster if the code doesn’t happen to block (for long).



              1. 1

                spawn_blocking in its current form might be removed or turned into a hint that the runtime should spin up a thread regardless.

            2. 1

              From the article :

              “If you still want to make sure the operation runs in the background and doesn’t block the current task either, you can simply spawn a regular task and do the blocking work inside it:”

              that means that it still pays off to use real async of you do not to block a task by one future.

              1. 1

                To be clear: potentially blocking the current task might be what you want. (e.g. if 99.9% of all operations fall under the threshold).

                1. 1

                  Sure. But the cost of spawning (without creating a new thread of not blocking) should be small, right? Basically in the order of a couple of allocations.

                  1. 1

                    spawning in async-std is exactly one allocation. Yes. spawning is cheap, you can do that often.