3 ms·

> If you use Tokio's single-threaded runtime, things get simpler. A major issue when dealing with the tokio runtime is Send bounds requirements, I don’t think

> If you use Tokio's single-threaded runtime, things get simpler. A major issue when dealing with the tokio runtime is Send bounds requirements, I don’t think the single-threaded runtime changes anything because these are API-level issues. You can use spawn_local to avoid migrations but you can do that on the multithreaded runtime just as well. And then a lot of tools and libraries which get layered over tokio (or assume a tokio environment) will require send futures anyway.

phamilton 3y ago
LocalSet does not require Send. https://docs.rs/tokio/latest/tokio/task/struct.LocalSet.html https://docs.rs/tokio/latest/tokio/task/struct.LocalSet.html EDIT: Sorry to join in the multiple responses. Clarity for others: "current_thread" by itself does not relax Send, and many libraries aren't configurable to make everything use LocalSet.
- deleted 3y ago
  [deleted]
- masklinn 3y ago
  I mentioned spawn_local, which is basically the same feature as localset (you can only spawn_local within the scope of a localset).
bryanlarsen 3y ago
Unless I'm mistaken, switching to a single threaded tokio runtime made Send requirements go away for me.
- veber-alex 3y ago
  Changing the type of runtime doesn't change the API at all. Even in a single threaded runtime spawn requires Send and you need to use LocalSet + spawn_local for !Send futures.
  - bryanlarsen 3y ago
    I wasn't using spawn. It's an I/O bound program with a big select! loop at it's core. Rust spit out errors about Send and I made them go away by switching to flavor = "current_thread".
    - masklinn 3y ago
      Would be nice if you could find it again, because from what I know of tokio I'd assume you made other unrelated changes which fixed the issue: tokio only has one runtime type, the flavour's effects are internal, the top-level future (run by Runtime::block_on) is always !Send, but from that you can only run Send futures (via spawn and spawn_blocking), unless you create a LocalSet. current_thread doesn't even create an implicit LocalSet, if you try to `spawn_local` from the top-level of a current_thread runtime you get a panic, exactly like a multi_thread runtime.
veber-alex 3y ago
What's the problem with Send bounds? So you use Arc instead of Rc.
- masklinn 3y ago
  The main problem is that for a future to be send, everything held across an await point has to be Send. Which is quite constraining and annoying, especially because this often does not play well with trait objects or `impl Trait` as people will commonly not think to add trait extra trait bounds. And of course it's an accumulation of trait bounds on everything, which makes for a downgrade in readability.
necubi 3y ago
That's incorrect, the Send bounds are only there in the multithreaded runtime (because it might need to Send a task across threads). The single threaded runtime will never do that, so its futures don't need to be Send. Somewhat relatedly, a major (early) stumbling block for me with the multithreaded runtime was trying to keep references across await points. While boxing them is always an option, things also got much easier when I realized that while &T is only Send if T is sync, _&mut T is send if T is send_.
- masklinn 3y ago
  > That's incorrect Is it? > the Send bounds are only there in the multithreaded runtime (because it might need to Send a task across threads). Tokio is interacted with using free functions which dynamically look up the current runtime, they could not have a different signature even if tokio had different runtime types, which it does not. > The single threaded runtime will never do that, so its futures don't need to be Send. Please do point to the ?Send spawn (not spawn_local) which supposedly exists for the current_thread runtime. You can't even spawn_local at the toplevel of the current_thread runtime.

phamilton 3y ago

LocalSet does not require Send. https://docs.rs/tokio/latest/tokio/task/struct.LocalSet.html https://docs.rs/tokio/latest/tokio/task/struct.LocalSet.html EDIT: Sorry to join in the multiple responses. Clarity for others: "current_thread" by itself does not relax Send, and many libraries aren't configurable to make everything use LocalSet.

deleted 3y ago
[deleted]
masklinn 3y ago
I mentioned spawn_local, which is basically the same feature as localset (you can only spawn_local within the scope of a localset).

bryanlarsen 3y ago

Unless I'm mistaken, switching to a single threaded tokio runtime made Send requirements go away for me.

veber-alex 3y ago
Changing the type of runtime doesn't change the API at all. Even in a single threaded runtime spawn requires Send and you need to use LocalSet + spawn_local for !Send futures.
- bryanlarsen 3y ago
  I wasn't using spawn. It's an I/O bound program with a big select! loop at it's core. Rust spit out errors about Send and I made them go away by switching to flavor = "current_thread".
  - masklinn 3y ago
    Would be nice if you could find it again, because from what I know of tokio I'd assume you made other unrelated changes which fixed the issue: tokio only has one runtime type, the flavour's effects are internal, the top-level future (run by Runtime::block_on) is always !Send, but from that you can only run Send futures (via spawn and spawn_blocking), unless you create a LocalSet. current_thread doesn't even create an implicit LocalSet, if you try to `spawn_local` from the top-level of a current_thread runtime you get a panic, exactly like a multi_thread runtime.

veber-alex 3y ago

What's the problem with Send bounds? So you use Arc instead of Rc.

masklinn 3y ago
The main problem is that for a future to be send, everything held across an await point has to be Send. Which is quite constraining and annoying, especially because this often does not play well with trait objects or `impl Trait` as people will commonly not think to add trait extra trait bounds. And of course it's an accumulation of trait bounds on everything, which makes for a downgrade in readability.

necubi 3y ago

That's incorrect, the Send bounds are only there in the multithreaded runtime (because it might need to Send a task across threads). The single threaded runtime will never do that, so its futures don't need to be Send. Somewhat relatedly, a major (early) stumbling block for me with the multithreaded runtime was trying to keep references across await points. While boxing them is always an option, things also got much easier when I realized that while &T is only Send if T is sync, _&mut T is send if T is send_.

masklinn 3y ago
> That's incorrect Is it? > the Send bounds are only there in the multithreaded runtime (because it might need to Send a task across threads). Tokio is interacted with using free functions which dynamically look up the current runtime, they could not have a different signature even if tokio had different runtime types, which it does not. > The single threaded runtime will never do that, so its futures don't need to be Send. Please do point to the ?Send spawn (not spawn_local) which supposedly exists for the current_thread runtime. You can't even spawn_local at the toplevel of the current_thread runtime.