Well, this one goes to my “save but never read” box.

Interesting idea indeed. I’ve never used async yet, but I’m always surprised at how the problem space seems to be much more complicated than what it initially looks like.

Great post!

I ran into this problem when working with gtk-rs. For every async library that you use, you have to look carefully if it requires a specific runtime. If you want to eg. make a HTTP request with reqwest you need to make sure to spawn a task on a tokio runtime running in the background.

Here’s my main takeaway with simpler language:

Rust doesn’t provide a way to abstract over async runtimes, so futures need to embed that somehow if they need access to it. So if you try to use functions intended for another runtime, you can get crashes.

This seems like it could be solved by providing an async runtime implementation in std that could be swapped out if desired (like the memory allocator).

The example FileDescriptorPollContext doesn’t really work. What if my runtime uses io-uring instead of polling? Those need very different interfaces to be sound. How do you abstract over that.