Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider relaxing the await-always-checkpoints rule to await-always-checkpoints-on-non-error #474

njsmith opened this issue Mar 18, 2018 · 2 comments · Fixed by #1058


Copy link

@njsmith njsmith commented Mar 18, 2018

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 await trio.sleep(1,5) then Python will raise TypeError: sleep() takes 1 positional argument ... before even invoking the function, so this call doesn't checkpoint.

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 await was on an operation that always raised an exception that you caught and then looped around on. And the proposed rule is easy to explain, though not quite as easy as the original rule.

Another nice thing is the rule is still sufficiently deterministic that we could check it automatically, as suggested in #152.


This comment has been minimized.

Copy link

@smurfix smurfix commented Apr 9, 2018



This comment has been minimized.

Copy link
Member Author

@njsmith njsmith commented Jan 25, 2019

This has been annoying me again recently, and I'm not thinking of serious downsides. Let's do it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.