Testing of asynchronous code #38
Description
Right now, rust's standard way of writing tests and the standard way of executing futures (tokio) are at odds with eachother. The test framework expects a panic on test failure - tokio catches panics and treats them as normal errors. The test framework tries to run multiple tests in parallel where it can - tokio immediately spawns one thread per CPU core when you run it. This makes testing asynchronous code pretty hard, and that's something we should fix.
I think to fix this, we need a simpler futures executor that doesn't include quite so many batteries. Instead, a run
function that just runs like a regular function - without trying to do anything with threads or panic catching. Ideally, in the name of keeping test and prod environments similar, I would suggest we at least consider making tokio that simpler executor*. Also possible would be taking something like toykio further, or potentially even going the full way to supporting #[test] async fn ...
in future.
*and separating all of the threading magic done by tokio out into a wrapper around a simpler core executor. This would be a big move, and I may be missing a whole bunch of reasons why its a bad idea, but on the bright side the extra flexibility could help people who
- want really high performance, and need custom control over how things work across threads in their program
- want a really light footprint for their code (nobody likes the app that spawns 8 threads just to transfer a file to another computer)
- don't expect high enough load for their program that the effort to make their code threadsafe is justified for the performance gains it would bring