Any extension of executors will require having a trait abstracting the executor used, and there just isn’t one in std yet. Your code already has to be tokio specific if you do something as mundane as spawn a task.
There are only a few things you need the specific runtime for:
- spawn
- IO
- timeout
But you can mix the executor and reactor doing the IO (not recommended but you can).
Similar you can run your own timer.
And you can abstract in various ways about all of this, sure with limitation, hence why there is no std-abstraction. But there are enough high profile libraries which do support multiple runtimes just fine.
But tokios preemting-cooperated threads to require any code which does any form of future multiplexing to:
- be tokio specific (which btw. isn't fully solving the problem)
- add a bunch of additional complexity, including memory and runtime overhead
If you multiplex features on tokio you must:
- use custom wakers to detect yields
- (and) do not poll futures in a "repeating" order (preferable fully random order).
This is a lot of additional complexity for something like a join_all (for a "small" N).
(reminds me I should check if I need to open an issue with futures-rs, as their join_all impl. was subtle broken last time I checked).
And even with that you have the problem that the multiplexed futures as subtle de-prioritized as they share a budged.
The problem I have with this feature is not that it's a bad idea, it isn't it's in general a good idea. The problem is that it completely overlooks the multiplexing case. And worse, further in subtle ways divides the ecosystem (that is what I'm worried about).
So maybe we could find a way to provide a std (or just common-library) standardized way for just that feature. (I mean it's a task local int,
it might not even need to be atomic, maybe. So there might be a way
which doesn't have the problem async-std standardization has).
There are only a few things you need the specific runtime for:
- spawn
- IO
- timeout
But you can mix the executor and reactor doing the IO (not recommended but you can).
Similar you can run your own timer.
And you can abstract in various ways about all of this, sure with limitation, hence why there is no std-abstraction. But there are enough high profile libraries which do support multiple runtimes just fine.
But tokios preemting-cooperated threads to require any code which does any form of future multiplexing to:
- be tokio specific (which btw. isn't fully solving the problem)
- add a bunch of additional complexity, including memory and runtime overhead
If you multiplex features on tokio you must:
- use custom wakers to detect yields
- (and) do not poll futures in a "repeating" order (preferable fully random order).
This is a lot of additional complexity for something like a join_all (for a "small" N).
(reminds me I should check if I need to open an issue with futures-rs, as their join_all impl. was subtle broken last time I checked).
And even with that you have the problem that the multiplexed futures as subtle de-prioritized as they share a budged.
The problem I have with this feature is not that it's a bad idea, it isn't it's in general a good idea. The problem is that it completely overlooks the multiplexing case. And worse, further in subtle ways divides the ecosystem (that is what I'm worried about).
So maybe we could find a way to provide a std (or just common-library) standardized way for just that feature. (I mean it's a task local int, it might not even need to be atomic, maybe. So there might be a way which doesn't have the problem async-std standardization has).