Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

gh-102780: Fix uncancel() call in asyncio timeouts#102815

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
gvanrossum merged 13 commits intopython:mainfrommainframeindustries:kristjan/uncancel
Mar 22, 2023
Merged

gh-102780: Fix uncancel() call in asyncio timeouts#102815

gvanrossum merged 13 commits intopython:mainfrommainframeindustries:kristjan/uncancel
Mar 22, 2023

Conversation

kristjanvalur
Copy link
Contributor

@kristjanvalurkristjanvalur commentedMar 18, 2023
edited
Loading

Record the previous cancellation state when enteringasyncio.timeout.Timeout
This allows us to useasyncio.timeout even when handling aCancelledError
exception. TheTimeout context manager will still not handle a CancelledError
if anew cancellation request is delivered in its scope.

  • Fix Timeout context manager
  • Add regression tests
  • Add documentiation, clarifying when it is appropriate to callTask.uncancel()

This needs to be backported to 3.11

vEpiphyte reacted with heart emoji
@gvanrossum
Copy link
Member

Thanks! This looks like the crux of the matter, and beautifully executed. I'll properly review it later this weekend.

kristjanvalur reacted with thumbs up emoji

Copy link
Member

@gvanrossumgvanrossum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I only really have doc nits, plus a feeling that maybe possibly TaskGroup could have the same problem?

I'm asking@kumaraditya303 to also review this, to make sure I didn't miss anything.

# handling this.
raise TimeoutError
raise TimeoutError from exc_val
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

This is a nice improvement that maybe ought to be called out in the commit message? (If you agree I can handle that when I merge it.)

Copy link
Contributor

@kumaraditya303kumaraditya303Mar 19, 2023
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Isn't this done by default? I see the same traceback with and without this on this example:

importasyncioasyncdeffunc():awaitasyncio.sleep(1)asyncdefmain():asyncwithasyncio.timeout(0.1):awaitfunc()asyncio.run(main())

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Not quite. When usingraise exc from ... theCancelledError instance gets stored inexc.__cause__, while without it, it gets stored inexc.__context__, and the connecting phrase in the output is different:

__cause__:

The above exception was the direct cause of the following exception:

__context__:

During handling of the above exception, another exception occurred:

(If both are set it follows__cause__.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Precicely. I has bothered me for a while that timeouts happen with the latter message, as if somehow, there was an error during exception handling. I wanted to use the opportunity to roll that fix in :)

Copy link
ContributorAuthor

@kristjanvalurkristjanvalurMar 20, 2023
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

This is a nice improvement that maybe ought to be called out in the commit message? (If you agree I can handle that when I merge it.)

Thank you, agreed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Not quite. When using raise exc from ... the CancelledError instance gets stored in exc.cause, while without it, it gets stored in exc.context, and the connecting phrase in the output is different:

Ah, right! I missed that. Adding a test would be nice.

kristjanvalur reacted with thumbs up emoji
Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I'll add that in a few hours.

Copy link
Contributor

@kumaraditya303kumaraditya303 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I would like to have a test for the exception chaining else LGTM. I leave the docs for Guido to review.

@gvanrossum Feel free to merge as you like.

Copy link
Member

@AlexWaygoodAlexWaygood left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

The docs read okay to me now, but I'll let Guido or Kumar merge since I'm not an asyncio expert!

Copy link
Member

@gvanrossumgvanrossum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Needs a news entry, otherwise LGTM.

@kristjanvalur
Copy link
ContributorAuthor

Needs a news entry, otherwise LGTM.

I'll have a go at it.

@gvanrossumgvanrossum changed the titlegh-102780gh-102780: Fix uncancel() call in asyncio timeoutsMar 22, 2023
@gvanrossumgvanrossum merged commit04adf2d intopython:mainMar 22, 2023
@gvanrossumgvanrossum added the needs backport to 3.11only security fixes labelMar 22, 2023
@miss-islington
Copy link
Contributor

Thanks@kristjanvalur for the PR, and@gvanrossum for merging it 🌮🎉.. I'm working now to backport this PR to: 3.11.
🐍🍒⛏🤖

miss-islington pushed a commit to miss-islington/cpython that referenced this pull requestMar 22, 2023
…2815)Also use `raise TimeOut from <CancelledError instance>` so that the CancelledError is setin the `__cause__` field rather than in the `__context__` field.(cherry picked from commit04adf2d)Co-authored-by: Kristján Valur Jónsson <sweskman@gmail.com>Co-authored-by: Guido van Rossum <gvanrossum@gmail.com>Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
@bedevere-bot
Copy link

GH-102923 is a backport of this pull request to the3.11 branch.

@bedevere-botbedevere-bot removed the needs backport to 3.11only security fixes labelMar 22, 2023
miss-islington added a commit that referenced this pull requestMar 22, 2023
Also use `raise TimeOut from <CancelledError instance>` so that the CancelledError is setin the `__cause__` field rather than in the `__context__` field.(cherry picked from commit04adf2d)Co-authored-by: Kristján Valur Jónsson <sweskman@gmail.com>Co-authored-by: Guido van Rossum <gvanrossum@gmail.com>Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
@kristjanvalurkristjanvalur deleted the kristjan/uncancel branchMarch 23, 2023 08:48
Fidget-Spinner pushed a commit to Fidget-Spinner/cpython that referenced this pull requestMar 27, 2023
Also use `raise TimeOut from <CancelledError instance>` so that the CancelledError is setin the `__cause__` field rather than in the `__context__` field.Co-authored-by: Guido van Rossum <gvanrossum@gmail.com>Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
warsaw pushed a commit to warsaw/cpython that referenced this pull requestApr 11, 2023
Also use `raise TimeOut from <CancelledError instance>` so that the CancelledError is setin the `__cause__` field rather than in the `__context__` field.Co-authored-by: Guido van Rossum <gvanrossum@gmail.com>Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
@graingert
Copy link
Contributor

does this need a corresponding change in asyncio.TaskGroup? eg here

ifself._parent_task.uncancel()==0:

@kristjanvalur
Copy link
ContributorAuthor

Interesting. It would be an issue if we entered a TaskGroup while cancellation state was not 0, e.g. during a finally of an outer cancel. I'm not qualified, though, to judge if that would ever be a real issue.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@puntonimpuntonimpuntonim left review comments

@AlexWaygoodAlexWaygoodAlexWaygood left review comments

@gvanrossumgvanrossumgvanrossum approved these changes

@kumaraditya303kumaraditya303kumaraditya303 approved these changes

@1st11st1Awaiting requested review from 1st11st1 is a code owner

@asvetlovasvetlovAwaiting requested review from asvetlovasvetlov is a code owner

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

8 participants
@kristjanvalur@gvanrossum@miss-islington@bedevere-bot@graingert@puntonim@kumaraditya303@AlexWaygood

[8]ページ先頭

©2009-2025 Movatter.jp