3 ms·
It's not always that simple. What if your sync lib has some callbacks, and you want to do something in the callbacks that requires async. You could argue that
by rklaehn 3y ago
It's not always that simple. What if your sync lib has some callbacks, and you want to do something in the callbacks that requires async.
You could argue that this mismatch exists even with rust itself, where you have Drop, which is sync, and you might have to do something in your drop that requires async, like closing a network connection.
You have to pass in some runtime handle that you can use to spawn a task to do what you have to do. This is definitely not simple and beginner friendly. Or even worse - say goodbye to RAII and tell people that they have to explicitly call an async shutdown fn.
- anderskaseorg 3y agoWithin your sync callback spawned via spawn_blocking, you can run async code with Handle::current().block_on(…): https://docs.rs/tokio/latest/tokio/runtime/struct.Handle.html#method.block_on https://docs.rs/tokio/latest/tokio/runtime/struct.Handle.htm....
- rklaehn 3y agoWhich panics if you don't call it in the right context. So now you have code which can only be used under certain circumstances and with one particular async runtime. Since when has it become acceptable in rust to have fns that just panic depending on the state of some thread local? That is one thing I really dislike about tokio. The thread local runtime is convenience over correctness, which is antithetical to what rust usually favours.