Remove dependency on `tokio/rt`

[AadamZ5]

Is your feature request related to a problem? Please describe.
Since this project is a library, it is unfavorable that it includes/requires the runtime from tokio/rt. If a project using the async-std runtime or some other runtime tries to use this project, the tokio runtime will now be needed to be running in addition to it, if there are no compatibility issues. Additionally, if a project uses a different version of tokio the runtimes may be incompatible.

Specifically, calls to tokio::spawn will panic if not called within a Tokio runtime. This is bad news for projects that include this crate and use a different runtime.

Describe the solution you'd like
Remove dependency on tokio/rt feature, and any calls to tokio::spawn in library code.

Describe alternatives you've considered
N/A

Additional context
A library crate bringing it's own async runtime is bad, and forces the consuming project of this crate to make more significant decisions about using the same runtime, having a larger binary size with two runtimes, or in the worst case, compatibility issues.

Note that removing the tokio/rt feature means that some portions that rely on tokio::task::JoinSet can not compile. Consider refactoring these areas with futures::stream::FuturesUnordered from the futures crate. Additionally, some spots that use tokio::spawn and JoinHandle may be replaceable with plain Pin<Box<dyn Future<Output = T> + Send + Sync + 'static>>s (but will now need polled/awaited somehow! spawn took care of that before). And in complex cases, you may even consider futures::future::shared to poll or await the same future from multiple spots.

I understand this may be a large refactor, perhaps one for a major release. Async Rust also gets a lot harder when we can't just spawn tasks, adding to the complexity of this refactor.

[4t145]

I can understand that it's good for a lib to support multi async runtime, but it may not be a top priority. If we decide to do so, we also need to replace the async channel, locks, signals, and cancellation tokens. Considering the overwhelming popularity and ecosystem of tokio, I think it is acceptable to only support tokio temporarily.

[AadamZ5]

Totally agree that this may not (or can not yet) be a top priority. However, implementing a runtime-agnostic library really might be the "most correct" way to implement an async library. Only the layer of the application that hosts the runtime should be responsible for spawning tasks on whatever runtime imo. Perhaps that requires this library to expose a run() method on some structs and shared inner state so the consumer of this library can decide how and where to spawn long-running tasks.

we also need to replace the async channel, locks, signals, and cancellation tokens

I am curious about why you'd need to replace the async channels, locks, signals, and cancellation tokens? Are those also tied to the runtime feature for Tokio? It doesn't seem so from the Tokio documentation and source, but maybe I'm missing something. I think that using those async primitives should be fine since they don't require spawning on the Tokio runtime.

Thinking about this project as a foundational building-block for Rust and AI, it's worth considering how we can ensure it's as robust and accessible as possible. You're absolutely right that Tokio is a common and popular choice that will serve most users well. Still, I can easily imagine someone wanting to integrate this with a custom async executor down the line. I think that supporting other executors would be a worthwhile long-term goal for the library. Should we keep this issue open?

[4t145]

Perhaps that requires this library to expose a run() method on some structs and shared inner state so the consumer of this library can decide how and where to spawn long-running tasks.

I think hyper can be a good reference.

I am curious about why you'd need to replace the async channels, locks, signals, and cancellation tokens?

You are right, just checked the source code and found it's ok to use them in different runtime.

Should we keep this issue open?

Let's keep this issue open.

[alexhancock]

@4t145 @AadamZ5 does anyone want to take an attempt at a PR for this?

[AadamZ5]

I'll take another look at this during the weekend, but I don't have a ton of confidence just yet. I don't regularly use this library, but I do have a bit of skills with async rust that I may be able to offer for some initial changes 🙂

I do think this will have some breaking changes, unless we go with an "adapter" route for the runtime to keep the ability to spawn, and figure out how to send calls to a global runtime adapter. My mind goes to how Iced accomplishes this with a runtime adapter in iced_futures::backend, but I have not yet seen how the adapter is used internally.

I will review the code at a high level this weekend, unless 4t145 is ready to move or has a large interest in this issue 🙂

[AadamZ5]

I've started with a few changes, going down the explicitly-returned-work-future route. This allows the caller of all APIs to be responsible for managing futures. I will open a draft PR for now as I continue to try out changes. If you don't like the direction it is going, let me know! No hard feelings.

There is a lot to change, and I am not using AI to refactor at this time. I do not feel comfortable using AI until I further understand the code base and architectural decisions. I may use AI to analyze some of the code base if I have a particularly tough time understanding what's going on.

So far, the changes have been able to be fairly localized to each spot using tokio::spawn(...) which is good, but I feel like I've only touched 2% of the code 😅