Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Consider relaxing the await-always-checkpoints rule to await-always-checkpoints-on-non-error #474
Currently, all the async functions in trio proper attempt to always issue a checkpoint on every call. The idea is that you want to be able to tell from reading your code where the checkpoints are, so this makes it more predictable – it's a static guarantee, so you don't have to reason carefully about unclear runtime conditions, and it's easy to explain to users.
However, I'm wondering if we might want to relax this slightly: maybe the rule should be, trio's async functions always checkpoint, unless they raise an exception (in which case there's no guarantee either way).
The reasoning here is that guaranteeing the checkpoint invariant for error paths turns out to be very tiresome and error-prone, both to implement and to test. Also, in some sense it's actually impossible to get this perfect – e.g. if you accidentally do
Furthermore, we can guess that usually users aren't going to be caring about checkpoints for operations that raise exceptions... for example, it'd be unusual to have a loop where the only
Another nice thing is the rule is still sufficiently deterministic that we could check it automatically, as suggested in #152.