-
-
Notifications
You must be signed in to change notification settings - Fork 348
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
Trace origin of cancellations #626
Comments
What makes this a bit tricky is that at the time someone calls We could unconditionally track whether a timeout occurred vs Another thing to think about: maybe this should be thought of as a special case of a more general problem, of tracing all kinds of wakeups through the system. You can imagine a special trace mode (maybe using the instrument API?) that records which takes ran when and which tasks woke which other tasks, so can track down these kinds of issues in general. |
Adding cancellation to instrumentation would certainly work, preferably as a two-step process. |
That's true, if we wanted to instrument all X-woke-Y relations, we'd probably want to separately instrument normal-path wakeups and cancel-path wakeups. Maybe: "X called |
The reason for a cancellation isn't always obvious (multiple cancel scopes, timeouts, …). It should thus be possible to attach a traceback to a
trio.Cancelled
exception that can help discover its origin when debugging.(Spin-off from #607)
The text was updated successfully, but these errors were encountered: