Using libraries depending on different async runtimes in one application

Someone who's actually tried this correct me please. My current understanding is:

• a bunch of libraries use tokio-specific stuff and fail when run by and executor that's not tokio's
• the official stance of async-std devs is to embrace the futures-* crates for libraries and use async-std in application code, but iiuc you can still use everything but the task module with other executors
• futures-* crates are supposed to work with any executor
• please don't boil this discussion down to just these two executors as there's a bunch more out there already!

Okay, here is what I have done:

I wrote a base crate for my RSS reader using reqwest as surf was not available at the time and even now I wouldn't be confident enough to use it (and didn't want to use libsoup because I want the base crate be pure rust). Async reqwest only works when executed by the tokio runtime. But since my UI is written in Gtk I have to use the glib main loop for all the async UI stuff.

So what I did was have a tokio runtime, a threadpool and a oneshot channel. I execute the async function of the base crate in a thread of the thread pool with the tokio runtime by blocking on it (it's in a separate thread anyway). And then execute all the UI stuff when receiving the result of that computation via the oneshot channel.

Luckily my use case is very simple as it usually only consist of a single "do something in the background" -> "update UI with result".

let (sender, receiver) = oneshot::channel::<ResultOfBackgroundTask>();

let tokio_runtime = self.tokio_runtime.clone();
let thread_future = async move {
    sender
        .send(tokio_runtime.block_on(background_task()))
        .unwrap();
};

let glib_future = receiver.map(move |res| {
    do_ui_stuff();
});

self.threadpool.spawn_ok(thread_future);
glib::MainContext::default().spawn_local(future);

So yes, I DID use two runtimes. Hope this helps anyway. And if someone knows a more convenient way to make these two runtimes work together please let me know =)

My recent answer to a similar question might help explain some of the reason the problem exists at all.

But I'm really curious what to do if I end up depending on both runtimes transitively.

Assuming you want to use one "main" runtime and manually delegate to others as needed, the question is "how do I execute futures that run on the ____ runtime from a different runtime?" which is a bit easier to answer. For example with tokio, you can keep a Runtime or Handle around somewhere and call functions like Handle::spawn. The returned JoinHandle looks like it should be pollable from any runtime. With async-std, I believe most tasks are pollable from any runtime, so from that angle it Just Works™. I'm not sure about other runtimes such as glib or bastion, but there is usually some way to spawn tasks on specific runtimes when necessary.

Aside from driver-bound futures like those that use I/O or timers, there are "extra" functions that you need to watch for like yield_now, block_in_place, and block_on - whether you or the libraries you use call them. Depending on the situation, they could cause panics or deadlocks if used improperly, and using multiple runtimes in one project can turn that into a more likely possibility.