I write libraries with async code quite alot. For this sometimes they have to spawn futures on an executor, because we shouldn't block the current task. This raises the question of how to tell a library which executor to use. In general the decision is up to the client application code.
Two options are generally available:
- pass around a
T: Executor - make a globally available
spawnfunction with a static executor
async_runtime takes the second approach for convenience.
Note: the actual crate name is naja_async_runtime because of some last minute name grabs on crates.io.
A runtime crate already exists, but it has a few issues that I try to avoid here:
- no need to box futures
- you can also spawn on a futures LocalPool (without threads), so you can also spawn
!Sendfutures, and avoid paying for thread synchronization when that's not appropriate. - doesn't have dependencies on network crates (and even juliex is optional, if you're on wasm or only want the LocalPool)
It also works on wasm. I have seen some wasm related code in runtime, but I haven't seen any examples or unit tests demonstrating that it works...
A downside of the design here is that there is no Runtime trait. You can't quickly write your own runtime without patching this crate. I have not yet seen the usefulness of creating other runtimes so for now this might be a non-issue.
There are currently no macro attributes for calling await directly in main either. Those might be added at some point in the future.
The currently supported runtimes are futures 0.3 LocalPool, juliex, wasm-bindgen-futures. I yet have to write benchmarks and might add the threadpool from the futures library at some point to compare with juliex.