Neither async-std nor tokio have mechanisms to handle errors robustly. The compiler does not give us errors nor warnings. Instead, the programmer needs to be careful and remember to add some extra code to handle errors and should at least think about panics. 9/29
-
-
Async-std crashes on panics. If an assertion fails in a task spawned from async-std within a unit test, the whole process crashes. No panics can slip through. 20/29pic.twitter.com/PTOTXiuOaE
Show this thread -
Crashing the entire process immediately is a bit annoying. If the whole process crashes, the test suite will not display the nicely formatted report of failed unit tests at the end. 21/29
Show this thread -
We need a panic handling strategy that is harsher than tokio's and gentler than async-std's. Why don't we propagate panics into the executor? 22/29
Show this thread -
In the case of async-std, it's not really obvious where the executor exactly is. Its thread pool is running in the background and we can only crash the process or perhaps let the user specify a custom panic handler. 23/29
Show this thread -
In tokio, the executor is the tokio Runtime instance, so instead of ignoring errors it'd make sense for Runtime::block_on() to propagate panics from tasks. 24/29pic.twitter.com/EF6m8hvgWK
Show this thread -
For now, suppose we had a very simple single-threaded runtime invoked by a function called run(), which propagates panics upwards. Don't think too much about it because I will tweet more about runtimes later... 25/29pic.twitter.com/qJaXb9eKbc
Show this thread -
In unit tests, panic propagation does the right thing by default, and it doesn't crash the whole test suite so we get a nice report at the end. 26/29pic.twitter.com/cQoG6uwvyo
Show this thread -
When run() propagates panics, it's up to the user to handle them however they wish. Panics can be ignored, logged, or simply left to continue unwinding. 27/29
Show this thread -
In summary: 28/29 1. Tasks are cancelled when dropped. 2. Tasks can't get accidentally dropped because we get compiler warnings. 3. Errors in tasks cannot get silently lost because we get compiler errors. 4. Unwrapping errors is easy. 5. Panics are propagated into the executor.
Show this thread -
That's all! This design isn't the "holy grail" of structured concurrency by any means, but it gets us very far with little effort and eliminates a lot of common pitfalls in async Rust. 29/29
Show this thread
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.