[Concurrency] improve cancellation handler to not hop and use caller execution context #80753
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ktoso
force-pushed
the
wip-improve-withTaskCancellationHandler-with-caller-execution
branch
2 times, most recently
from
de601db to
1303d99
Compare
|
This is blocked by incorrect behavior of the caller execution on a closure rdar://149107104 |
ktoso
added
the
concurrency
ktoso
force-pushed
the
wip-improve-withTaskCancellationHandler-with-caller-execution
branch
from
1303d99 to
a583630
Compare
The problem is that even with the #isolation parameter the non-Sendable async closure operation _still_ would potentially hop off the caller isolation. We introduced this change because the plan was the non-Sendable closure would run on the isolated parameter's isolation, but that's not actually the case: Instead, we can use the @execution(caller) on the function and closure, in order to guarantee there is no hop between those at all, and developers can trust that adding this cancellation handler will not cause any unexpected isolation changes and hops. The API was always documented to not hop as we execute the operation, so this brings the correct and expected behavior. resolves rdar://140110775
ktoso
force-pushed
the
wip-improve-withTaskCancellationHandler-with-caller-execution
branch
from
a583630 to
9ea3293
Compare
|
Now blocked on rdar://150017382 |
…-caller-execution
|
@swift-ci please smoke test |
ktoso
commented
May 15, 2025
| @@ -63,6 +63,8 @@ endif() | |||
| list(APPEND SWIFT_RUNTIME_CONCURRENCY_SWIFT_FLAGS | |||
| "-enable-experimental-feature" | |||
| "IsolatedAny" | |||
| "-enable-experimental-feature" | |||
| "ExecutionAttribute" | |||
There was a problem hiding this comment.
we can remove this now
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The problem is that even with the #isolation parameter the non-Sendable
async closure operation still would potentially hop off the caller
isolation. We introduced this change because the plan was the
non-Sendable closure would run on the isolated parameter's isolation,
but that's not actually the case:
Instead, we can use the @execution(caller) on the function and closure,
in order to guarantee there is no hop between those at all, and
developers can trust that adding this cancellation handler will not
cause any unexpected isolation changes and hops. The API was always
documented to not hop as we execute the operation, so this brings the
correct and expected behavior.
resolves rdar://140110775