5 ms·

rust team needs to abandon their own execution runtime and just bless tokio and pull it into std. They're doing nobody any favors right now

steveklabnik 3y ago
That is never going to happen, for both good reasons and bad reasons.
- VWWHFSfQ 3y ago
  Yeah I figured. Fragmentation by design.
  - steveklabnik 3y ago
    One person's "fragmentation" is another's "supporting multiple use cases is important, even if their requirements are divergent."
estebank 3y ago
The Rust team doesn't have its own execution runtime. Tokio is certainly the closest thing to the "default".
Animats 3y ago
I'm struggling to get tokio out of my executable. I'm not using it, but stuff keeps pulling it in. Async contamination is a huge problem. For highly concurrent code with threads running at different priority levels, if async gets in there it makes a mess.
- arijun 3y ago
  Sorry if this is ignorant, but what’s the difference between async and concurrent? Is the problem that async schedules everything itself?
  - Animats 3y ago
    "Async" is optimized for the special case of a server that is I/O bound and spends most of its time waiting for network traffic. This covers most webcrap, so many people who do nothing else want that. It also works like JavaScript, a model with which many web programmers are comfortable. It's a bad fit if you have enough compute work to keep all the CPUs busy. Then you're dealing with thread priorities, infinite overtaking and starvation, fairness, and related issues.
    - flylikeabanana 3y ago
      Isn't this the difference between concurrency and parallelism? Like you said, Tokio (I'm coming from effect systems in Scala, the current generation of which take heavy inspiration from Tokio) is good for informing your program when your code is blocked so it can perform some useful work elsewhere, which is a fundamentally different problem to parallelizing code. So if I'm understanding your complaint right it's that Tokio sneaks in when its concurrency features aren't particularly useful for parallelization?
      - Animats 3y ago
        Correct. I have an unusual application, a metaverse client for big 3D worlds. It has to deal with a flood of data while maintaining a 60 FPS frame rate. It's essential that the rendering thread(s) not be delayed, even though other background threads are compute bound dealing with a flood of incoming 3D assets. This does not fit well with the async model. This sort of thing comes up in games, real time control, and robotics, but is not something often seen in web-related software.
        yazaddaruvala 3y ago
        > This sort of thing comes up in games, real time control, and robotics, but is not something often seen in web-related software. I think you're not familiar with web-related software. > It's essential that the rendering thread(s) not be delayed, even though other background threads are compute bound dealing with a flood of incoming 3D assets. This is exactly how the browser behaves, and why Javascript needs to be entirely async on the main thread. For your application it should be very easy to spin up a render thread (pinned to a single core or whatever priority mechanisms you want to use) that loops, and use message passing to get the results from Tokio based futures.
- jrockway 3y ago
  You know what they say about libraries; if you're not having problems, you're not using enough of them. On a more serious note, "I want other people to write my code, but they're not following my standards" is rarely a sympathetic point of view.
sanxiyn 3y ago
Given that Linux kernel is using async Rust which is implemented on top of kernel workqueue, and tokio won't be usable in kernel, it is a good thing tokio is not blessed. That's what enables both userland and kernel to use async Rust.
- jenadine 3y ago
  There can be both a "blessed" executor, while staying optional for such cases. For example, Rust std lib has blessed Mutex. Even though these can't be used in the kernel, it is still good to have them in the std lib for >90% of normal crates.

steveklabnik 3y ago

That is never going to happen, for both good reasons and bad reasons.

VWWHFSfQ 3y ago
Yeah I figured. Fragmentation by design.
- steveklabnik 3y ago
  One person's "fragmentation" is another's "supporting multiple use cases is important, even if their requirements are divergent."

estebank 3y ago

The Rust team doesn't have its own execution runtime. Tokio is certainly the closest thing to the "default".

Animats 3y ago

I'm struggling to get tokio out of my executable. I'm not using it, but stuff keeps pulling it in. Async contamination is a huge problem. For highly concurrent code with threads running at different priority levels, if async gets in there it makes a mess.

arijun 3y ago
Sorry if this is ignorant, but what’s the difference between async and concurrent? Is the problem that async schedules everything itself?
- Animats 3y ago
  "Async" is optimized for the special case of a server that is I/O bound and spends most of its time waiting for network traffic. This covers most webcrap, so many people who do nothing else want that. It also works like JavaScript, a model with which many web programmers are comfortable. It's a bad fit if you have enough compute work to keep all the CPUs busy. Then you're dealing with thread priorities, infinite overtaking and starvation, fairness, and related issues.
  - flylikeabanana 3y ago
    Isn't this the difference between concurrency and parallelism? Like you said, Tokio (I'm coming from effect systems in Scala, the current generation of which take heavy inspiration from Tokio) is good for informing your program when your code is blocked so it can perform some useful work elsewhere, which is a fundamentally different problem to parallelizing code. So if I'm understanding your complaint right it's that Tokio sneaks in when its concurrency features aren't particularly useful for parallelization?
    - Animats 3y ago
      Correct. I have an unusual application, a metaverse client for big 3D worlds. It has to deal with a flood of data while maintaining a 60 FPS frame rate. It's essential that the rendering thread(s) not be delayed, even though other background threads are compute bound dealing with a flood of incoming 3D assets. This does not fit well with the async model. This sort of thing comes up in games, real time control, and robotics, but is not something often seen in web-related software.
      - yazaddaruvala 3y ago
        > This sort of thing comes up in games, real time control, and robotics, but is not something often seen in web-related software. I think you're not familiar with web-related software. > It's essential that the rendering thread(s) not be delayed, even though other background threads are compute bound dealing with a flood of incoming 3D assets. This is exactly how the browser behaves, and why Javascript needs to be entirely async on the main thread. For your application it should be very easy to spin up a render thread (pinned to a single core or whatever priority mechanisms you want to use) that loops, and use message passing to get the results from Tokio based futures.
jrockway 3y ago
You know what they say about libraries; if you're not having problems, you're not using enough of them. On a more serious note, "I want other people to write my code, but they're not following my standards" is rarely a sympathetic point of view.

sanxiyn 3y ago

Given that Linux kernel is using async Rust which is implemented on top of kernel workqueue, and tokio won't be usable in kernel, it is a good thing tokio is not blessed. That's what enables both userland and kernel to use async Rust.

jenadine 3y ago
There can be both a "blessed" executor, while staying optional for such cases. For example, Rust std lib has blessed Mutex. Even though these can't be used in the kernel, it is still good to have them in the std lib for >90% of normal crates.