-
-
Notifications
You must be signed in to change notification settings - Fork 345
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
TaskStatus.started() being a no-op if cancelled can cause deadlocks #2895
Comments
Maybe started() should raise an exception, RuntimeError or whatever, if the
call to `start` has ever been in the cancelled state?
…On Fri, Dec 1, 2023, 10:06 Joshua Oreman ***@***.***> wrote:
TaskStatus.started() starts with the logic:
# If the old nursery is cancelled, then quietly quit now; the child
# will eventually exit on its own, and we don't want to risk moving
# children that might have propagating Cancelled exceptions into
# a place with no cancelled cancel scopes to catch them.
assert self._old_nursery._cancel_status is not None
if self._old_nursery._cancel_status.effectively_cancelled:
return
However, this logic does not hold if the function calling started() then
proceeds to do its work in a shielded cancel scope. This describes
trio-asyncio, and caused the deadlock reported in
python-trio/trio-asyncio#115
<python-trio/trio-asyncio#115>.
trio-asyncio can work around this by shielding the call to start(), but
maybe Trio could also reconsider the logic in started()? I think at
minimum it's safe to move the task if the new nursery is also effectively
cancelled. It should also be safe to move the task if no Cancelled
exception has actually been raised yet, but that's hard to track and maybe
not worth it?
—
Reply to this email directly, view it on GitHub
<#2895>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEU42HCD6HJ6OOQFBXNQVDYHIMCPAVCNFSM6AAAAABADGRH7KVHI2DSMVQWIX3LMV43ASLTON2WKOZSGAZDCMZVGYZDKMQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
i noticed this too after hitting that trio-asyncio bug a few months ago. at the time, i wrote up a report and a corresponding patchset to propose, but i got busy and never got around to cleaning up the patchset and posting both. here's that old report (it is partially repetitive of what you wrote above, but i share it still because it notes some other symptoms alongside the deadlock and compares some alternatives for fixing this):
a comment in Lines 791 to 796 in 4f17d2b
proposal: make there are some different possible approaches to doing that:
here's a proposed patchset for the first option: master...3e87b5c DECEMBER EDIT: i've rebased that patchset onto master, adapted it for #1696 and cleaned it up. i will open a PR to propose it. |
TaskStatus.started()
starts with the logic:However, this logic does not hold if the function calling started() then proceeds to do its work in a shielded cancel scope. This describes trio-asyncio, and caused the deadlock reported in python-trio/trio-asyncio#115.
trio-asyncio can work around this by shielding the call to
start()
, but maybe Trio could also reconsider the logic instarted()
? I think at minimum it's safe to move the task if the new nursery is also effectively cancelled. It should also be safe to move the task if no Cancelled exception has actually been raised yet, but that's hard to track and maybe not worth it?The text was updated successfully, but these errors were encountered: