Defer KI if trio is doing IO #3233
Conversation
Co-authored-by: Joshua Oreman <[email protected]>
|
codecov failure doesn't make any sense and seems to be a recent thing. I'm inclined to believe it's some change in how they normalize file names but I don't think it's worth chasing down for now. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #3233 +/- ##
====================================================
- Coverage 100.00000% 99.95275% -0.04726%
====================================================
Files 124 124
Lines 19047 19047
Branches 1287 1287
====================================================
- Hits 19047 19038 -9
- Misses 0 8 +8
- Partials 0 1 +1
🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Is the change to the abort parameter tightly bound to the other changes in this PR? Can it be pulled out into a separate PR?
This is a daunting PR to review, with one former PR and 4 related issues, and changes in 23 files, and it might be more manageable if it got split up.
It'd also be nice if the PR summarized the state of discussion, I don't know if KI-deferral has been unanimously agreed to be the better way to do it, or if there's up- & downsides.
Sorry for the non-review review <3
src/trio/_core/_traps.py
Outdated
| `~trio.Cancelled` exception, but we may use this mechanism to | ||
| raise other exceptions in the future; you should raise whatever | ||
| you're given.) Either of the approaches sketched below can | ||
| work:: |
There was a problem hiding this comment.
is this block of text modified? Or just reformatted? It's hard to see in the diff
There was a problem hiding this comment.
Modified, specifically the second to last sentance (which turns into two). I copied this over from the old PR which might explain the formatting...
|
I can do the change to abort fn as a follow up -- it needs this change because the reason it's a function is because KI can be raised (which this change stops), but this change doesn't depend on it. This isn't so much a summary but see #733 (comment) (this is ~just about that issue, other issues being closed is just because this is a Good Idea and unlocks easy fixes). |
src/trio/_core/_traps.py
Outdated
| `~trio.Cancelled` exception, but we may use this mechanism to | ||
| raise other exceptions in the future; you should raise whatever | ||
| you're given.) Either of the approaches sketched below can | ||
| work:: |
There was a problem hiding this comment.
Modified, specifically the second to last sentance (which turns into two). I copied this over from the old PR which might explain the formatting...
| @@ -351,6 +351,8 @@ async def to_thread_run_sync( | |||
| if limiter is None: | |||
| limiter = current_default_thread_limiter() | |||
|
|
|||
| # TODO: cancel_register can probably be a single element tuple for typing reasons | |||
There was a problem hiding this comment.
This helps in stopping people from indexing above 0, but it breaks a bunch of current code that manipulates the content of the list. Ideally it'd be some minimalist wrapper class.
There was a problem hiding this comment.
would a deque with maxlen=1 help?
There was a problem hiding this comment.
I wouldn't expect typing to take the maxlen into account
| return | ||
| self.main_task._attempt_delivery_of_pending_ki() | ||
| with suppress(RunFinishedError): | ||
| self.entry_queue.run_sync_soon(self.main_task_nursery.cancel_scope.cancel) |
There was a problem hiding this comment.
nice, this will be easy to harmonize with #3232 🚀
| _core.run(check_protected_kill) | ||
|
|
||
| # TODO: be consistent about providing Cancelled tree as __context__ |
Supersedes #1537.
As with that, fixes #151, first step of #733.
Additionally, fixes part of #3007 (not intentionally, just because it has to be done in order to still raise a KI. I should add a test.).