Fix EventLoopFuture and EventLoopPromise under strict concurrency checking
#2654
+423
−274
Conversation
This file contains 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
FranzBusch
force-pushed
the
fb-event-loop-future-sendable
branch
2 times, most recently
from
d95beaf
to
b438afd
Compare
glbrntt
requested changes
Feb 19, 2024
Comment on lines
194
to
196
| public func succeed(eventLoopBoundValue: Value) { | ||
| self._resolve(eventLoopBoundResult: .success(eventLoopBoundValue)) | ||
| } |
There was a problem hiding this comment.
I'm not sure this is the right spelling; the pattern we have for functions which must be called on the right EL with runtime assertions are synchronous views (e.g. ChannelPipeline.SynchronousOperations and Channel.syncOptions).
It also skirts around the slight oddity with this API in that you could call this function with a Sendable i.e. not EL bound value with no ill side effect.
There was a problem hiding this comment.
I agree. I removed those loopBound APIs from this PR since they are really part of the AssumeIsolated PR
… checking # Motivation We need to tackle the remaining strict concurrency checking related `Sendable` warnings in NIO. The first place to start is making sure that `EventLoopFuture` and `EventLoopPromise` are properly annotated. # Modification In a previous apple#2496, @weissi changed the `@unchecked Sendable` conformances of `EventLoopFuture/Promise` to be conditional on the sendability of the generic `Value` type. After having looked at all the APIs on the future and promise types as well as reading the latest Concurrency evolution proposals, specifically the [Region based Isolation](https://github.com/apple/swift-evolution/blob/main/proposals/0414-region-based-isolation.md), I came to the conclusion that the previous `@unchecked Sendable` annotations were correct. The reasoning for this is: 1. An `EventLoopPromise` and `EventLoopFuture` pair are tied to a specific `EventLoop` 2. An `EventLoop` represents an isolation region and values tied to its isolation are not allowed to be shared outside of it unless they are disconnected from the region 3. The `value` used to succeed a promise often come from outside the isolation domain of the `EventLoop` hence they must be transferred into the promise. 4. The isolation region of the event loop is enforced through `@Sendable` annotations on all closures that receive the value in some kind of transformation e.g. `map()` 5. Any method on `EventLoopFuture` that combines itself with another future must require `Sendable` of the other futures `Value` since we cannot statically enforce that futures are bound to the same event loop i.e. to the same isolation domain Due to the above rules, this PR adds back the `@unchecked Sendable` conformances to both types. Furthermore, this PR revisits every single method on `EventLoopPromise/Future` and adds missing `Sendable` and `@Sendable` annotation where necessary to uphold the above rules. A few important things to call out: - Since `transferring` is currently not available this PR requires a `Sendable` conformance for some methods on `EventLoopPromise/Future` that should rather take a `transffering` argument - To enable the common case where a value from the same event loop is used to succeed a promise I added two additional methods that take a `eventLoopBoundResult` and enforce dynamic isolation checking. We might have to do this for more methods once we adopt those changes in other targets/packages. # Result After this PR has landed our lowest level building block should be inline with what the rest of the language enforces in Concurrency. The `EventLoopFuture.swift` produces no more warnings under strict concurrency checking on the latest 5.10 snapshots.
FranzBusch
force-pushed
the
fb-event-loop-future-sendable
branch
from
b438afd
to
a5c83a4
Compare
FranzBusch
force-pushed
the
fb-event-loop-future-sendable
branch
from
a5c83a4
to
5d20621
Compare
glbrntt
reviewed
Feb 19, 2024
Lukasa
added
the
patch-version-bump-only
Lukasa
approved these changes
Feb 28, 2024
glbrntt
approved these changes
Mar 4, 2024
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.
Motivation
We need to tackle the remaining strict concurrency checking related
Sendablewarnings in NIO. The first place to start is making sure thatEventLoopFutureandEventLoopPromiseare properly annotated.Modification
In a previous #2496, @weissi changed the
@unchecked Sendableconformances ofEventLoopFuture/Promiseto be conditional on the sendability of the genericValuetype. After having looked at all the APIs on the future and promise types as well as reading the latest Concurrency evolution proposals, specifically the Region based Isolation, I came to the conclusion that the previous@unchecked Sendableannotations were correct. The reasoning for this is:EventLoopPromiseandEventLoopFuturepair are tied to a specificEventLoopEventLooprepresents an isolation region and values tied to its isolation are not allowed to be shared outside of it unless they are disconnected from the regionvalueused to succeed a promise often come from outside the isolation domain of theEventLoophence they must be transferred into the promise.@Sendableannotations on all closures that receive the value in some kind of transformation e.g.map()orwhenComplete()EventLoopFuturethat combines itself with another future must requireSendableof the other futuresValuesince we cannot statically enforce that futures are bound to the same event loop i.e. to the same isolation domainDue to the above rules, this PR adds back the
@unchecked Sendableconformances to both types. Furthermore, this PR revisits every single method onEventLoopPromise/Futureand adds missingSendableand@Sendableannotation where necessary to uphold the above rules. A few important things to call out:transferringis currently not available this PR requires aSendableconformance for some methods onEventLoopPromise/Futurethat should rather take atransfferingargumenteventLoopBoundResultand enforce dynamic isolation checking. We might have to do this for more methods once we adopt those changes in other targets/packages.Result
After this PR has landed our lowest level building block should be inline with what the rest of the language enforces in Concurrency. The
EventLoopFuture.swiftproduces no more warnings under strict concurrency checking on the latest 5.10 snapshots.