I think there's some confusion. have published an async_runtime for futures 0.3. It has no reactor. It allows you to set a thread global executor per thread to decide whether you want the globally available
rt::spawn method to spawn on the current thread or in a threadpool.
It all works, and you can even spawn network related futures from romio, and even from tokio. Every future is responsible for waking up the task when progress can be made, but what exactly that means really depends on the specifics of the future, and I think libraries generating futures should take care of that themselves.
It's true that for operating system IO, rust libraries often use
mio. And both
tokio have a reactor object for interfacing between mio and the task system.
It could be argued that it would be best if there was generic reactor crate, that different IO libraries could use rather than every library roll their own. However it's not in my opinion part of the runtime directly.
Since it's an interface to the OS, something like mio or a reactor could one day also be in stdlib, but I think a first step is to have it as a crate that is generic enough for different libraries, and not tied to specifics of one of them.
In any case both can be independently supported.