[Concurrency] improve cancellation handler to not hop and use caller execution context #80753
Conversation
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
2 times, most recently
from
a583630 to
9ea3293
Compare
|
Now blocked on rdar://150017382 |
|
@swift-ci please smoke test |
| @@ -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
|
@swift-ci smoke test |
1 similar comment
|
@swift-ci smoke test |
|
Good news, this was now unblocked by #82858 |
ktoso
force-pushed
the
wip-improve-withTaskCancellationHandler-with-caller-execution
branch
2 times, most recently
from
f0ecf2d to
25a963e
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 move to nonisolated(nonsending) [Concurrency] latest cancellation handler is emit into client; no ABI entry
ktoso
force-pushed
the
wip-improve-withTaskCancellationHandler-with-caller-execution
branch
from
25a963e to
be2b2ad
Compare
| #if !$Embedded | ||
| @backDeployed(before: SwiftStdlib 6.0) | ||
| #endif | ||
| @_alwaysEmitIntoClient |
There was a problem hiding this comment.
going with just AEIC those; we keep changing concurrency annotations and those methods are so small that AEIC for them is going to be fine anyway (as most of concurrency API already are like this)
| defer { unsafe _taskRemoveCancellationHandler(record: record) } | ||
|
|
||
| return try await operation() | ||
| } |
There was a problem hiding this comment.
This way we stay on the caller for as long as possible, and the closure is also invoked on it. This improves the way we don't hop away from the caller unnecessarily anymore
|
@swift-ci please smoke test |
… clopsure inherits isolation
|
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 |
|
@swift-ci please smoke test |
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