[Concurrency] Correct enqueue behavior in with... functions by adopting nonisolated(nonsending) #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
Contributor
Author
|
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
2 times, most recently
from
a583630 to
9ea3293
Compare
Contributor
Author
|
Now blocked on rdar://150017382 |
Contributor
Author
|
@swift-ci please smoke test |
ktoso
commented
May 15, 2025
Contributor
|
@swift-ci smoke test |
1 similar comment
Contributor
|
@swift-ci smoke test |
Contributor
Author
|
Good news, this was now unblocked by #82858 |
ktoso
force-pushed
the
wip-improve-withTaskCancellationHandler-with-caller-execution
branch
3 times, most recently
from
25a963e to
be2b2ad
Compare
ktoso
commented
Jul 8, 2025
ktoso
commented
Jul 8, 2025
Contributor
Author
|
@swift-ci please smoke test |
Contributor
Author
|
This is almost unblocked, we need to fix throwing nonisolated nonsending (caller isolated) closures to not lose isolation -- rdar://155313349 And there seems to be a problem with noncopyable types and nonisolated nonsending (caller isolated) closures as well; It shows up in Giving it a run to see if anything else |
Contributor
Author
|
@swift-ci please smoke test |
Contributor
Author
|
By now this is unlikely to make it into 6.2.0 |
ktoso
force-pushed
the
wip-improve-withTaskCancellationHandler-with-caller-execution
branch
from
9f1e063 to
0e5a262
Compare
ktoso
changed the title
Contributor
Author
|
@swift-ci please smoke test |
Contributor
Author
|
Fixing all the ABI tests to follow. |
ktoso
force-pushed
the
wip-improve-withTaskCancellationHandler-with-caller-execution
branch
from
fcdc60b to
01e0397
Compare
ktoso
force-pushed
the
wip-improve-withTaskCancellationHandler-with-caller-execution
branch
from
01e0397 to
9a2d287
Compare
Contributor
Author
|
@swift-ci please smoke test |
ktoso
added a commit
to ktoso/swift
that referenced
this pull request
Oct 16, 2025
This is the minimal set of changes from swiftlang#80753 to specifically address the with...Continuation APIs re-enqueueing tasks when they need not have to. Resolves rdar://162192512 resolves
Contributor
Author
|
@gottesmm will investigate the optimizer approach to solving this instead; seems we're missing the optimization in debug mode |
ktoso
added a commit
to ktoso/swift
that referenced
this pull request
Oct 21, 2025
This is the minimal set of changes from swiftlang#80753 to specifically address the with...Continuation APIs re-enqueueing tasks when they need not have to. In the specific case of the continuation APIs we move to adopt the `nonisolated(nonsending)` feature, however there will be a follow-up here to improve how we handle enqueues with a Serial Executor that is also a Task Executor at the same time Resolves rdar://162192512
ktoso
added a commit
to ktoso/swift
that referenced
this pull request
Oct 21, 2025
This is the minimal set of changes from swiftlang#80753 to specifically address the with...Continuation APIs re-enqueueing tasks when they need not have to. In the specific case of the continuation APIs we move to adopt the `nonisolated(nonsending)` feature, however there will be a follow-up here to improve how we handle enqueues with a Serial Executor that is also a Task Executor at the same time Resolves rdar://162192512
ktoso
added a commit
to ktoso/swift
that referenced
this pull request
Oct 22, 2025
This is the minimal set of changes from swiftlang#80753 to specifically address the with...Continuation APIs re-enqueueing tasks when they need not have to. In the specific case of the continuation APIs we move to adopt the `nonisolated(nonsending)` feature, however there will be a follow-up here to improve how we handle enqueues with a Serial Executor that is also a Task Executor at the same time Resolves rdar://162192512
ktoso
added a commit
to ktoso/swift
that referenced
this pull request
Oct 29, 2025
This is the minimal set of changes from swiftlang#80753 to specifically address the with...Continuation APIs re-enqueueing tasks when they need not have to. In the specific case of the continuation APIs we move to adopt the `nonisolated(nonsending)` feature, however there will be a follow-up here to improve how we handle enqueues with a Serial Executor that is also a Task Executor at the same time Resolves rdar://162192512
ktoso
force-pushed
the
wip-improve-withTaskCancellationHandler-with-caller-execution
branch
from
9a2d287 to
3ceae73
Compare
Contributor
Author
|
@swift-ci please smoke test |
jamieQ
reviewed
Dec 16, 2025
Contributor
jamieQ
left a comment
jamieQ
left a comment
There was a problem hiding this comment.
some further unsolicited feedback/questions for your consideration :)
| func globalTestFunc(isolation: isolated (any Actor)? = #isolation) async { | ||
| isolation!.assertIsolated("wat in \(#function)!") | ||
| await withTaskCancellationHandler { | ||
| isolation!.assertIsolated("wat in \(#function)!") |
Contributor
There was a problem hiding this comment.
might be good to test that this works without a capture of the isolated parameter too, to ensure it's relying on the nonisolated(nonsending)-ness of the closure, and not the isolated capture logic.
ktoso
force-pushed
the
wip-improve-withTaskCancellationHandler-with-caller-execution
branch
3 times, most recently
from
eda5dc2 to
aa0fb44
Compare
This drastically lessens the number of unexpected task enqueues and hops that these APIs cause, and therefore improves performance and even correctness in a few cases (like the withContinuation APIs)
ktoso
force-pushed
the
wip-improve-withTaskCancellationHandler-with-caller-execution
branch
from
aa0fb44 to
13e6b40
Compare
Contributor
Author
|
@swift-ci please smoke test |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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: an "re-enqueue" can still happens in those cases.
Instead, we can use the nonisolated(nonsending) 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.
This corrects the following APIs:
as well as task group's next() and related ones...
This gets down the "re-enqueue" count of those methods by far, and makes all these more reliable and predictable.
resolves rdar://140110775
resolves rdar://162192512