-
Notifications
You must be signed in to change notification settings - Fork 316
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sendable
support
#1795
Sendable
support
#1795
Conversation
@@ -3168,6 +3168,7 @@ | |||
SDKROOT = iphoneos; | |||
SUPPORTS_MACCATALYST = YES; | |||
SWIFT_OPTIMIZATION_LEVEL = "-Onone"; | |||
SWIFT_STRICT_CONCURRENCY = targeted; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll see if we keep this or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's not a bad idea to keep this so we ensure we maintain this level of correctness prior to Swift 6.0
0044e54
to
9bf8b8e
Compare
abdf7a2
to
2aa6468
Compare
b5c1b42
to
faed2ac
Compare
The type is now immutable, so the compiler ensures it's thread-safe. For CSDK-379. Extracted #1795 to make it easier to review this fix in isolation.
For [CSDK-379]. Extracted #1795 to make it easier to review this fix in isolation. Also made `ASN1ObjectIdentifierBuilder` an `enum` since we don't need to create instances of it to use it.
7931d7e
to
0e2538d
Compare
This is almost ready, but it will be a lot easier to review once all those dependent PRs are merged. |
9bd795e
to
cc09992
Compare
The type is now immutable, so the compiler ensures it's thread-safe. For CSDK-379. Extracted #1795 to make it easier to review this fix in isolation.
The type is now immutable, so the compiler ensures it's thread-safe. For [CSDK-379]. Extracted from #1795 to make it easier to review this in isolation.
51387b7
to
5645f05
Compare
The type is now immutable, so the compiler ensures it's thread-safe. For [CSDK-379]. Extracted from #1795 to make it easier to review this in isolation. [CSDK-379]: https://revenuecats.atlassian.net/browse/CSDK-379?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
For [CSDK-379]. Extracted from #1795 to make it easier to review this in isolation. Also made `ASN1ObjectIdentifierBuilder` an `enum` since we don't need to create instances of it to use it. [CSDK-379]: https://revenuecats.atlassian.net/browse/CSDK-379?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
The type is now immutable, so the compiler ensures it's thread-safe. For [CSDK-379]. Extracted from #1795 to make it easier to review this in isolation. [CSDK-379]: https://revenuecats.atlassian.net/browse/CSDK-379?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
This is ready to review @RevenueCat/core-sdk |
Bump @RevenueCat/core-sdk |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😮💨
Nice work.
Merging this unless somebody else has any concerns or wants more time to look at it @RevenueCat/core-sdk |
extension OperationDispatcher { | ||
|
||
static func dispatchOnMainActor(_ block: @MainActor @escaping @Sendable () -> Void) { | ||
if #available(macOS 10.15, iOS 13.0, watchOS 6.0, tvOS 13.0, *) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is cool
} else { | ||
workerQueue.async(execute: block) | ||
DispatchQueue.main.async(execute: block) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this be self.mainQueue
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yeah good call.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ohhh right, that makes sense. Could you add a comment for the future?
private let maxJitterInSeconds: Double = 5 | ||
|
||
static let `default`: OperationDispatcher = .init() | ||
|
||
func dispatchOnMainThread(_ block: @escaping () -> Void) { | ||
func dispatchOnMainThread(_ block: @escaping @Sendable () -> Void) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be made private now? Is there any scenario where we should choose to go with main thread and not main actor even when Swift Concurrency is available?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Eventually we can get rid of this, but that seems like a bigger change. For existing code that does not use the new Swift "structured" concurrency, we might not want to change the semantics if we don't need to.
There's still a few places using dispatchOnMainThread
that we might not want to change until we use @MainActor
(or other custom actor
s) in more places.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me know what you think, we can migrate more of these to dispatchOnMainActor
in a following PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
**This is an automatic release.** ### Bugfixes * `watchOS`: fixed crash when ran on single-target apps with Xcode 14 and before `watchOS 9.0` (#1895) via NachoSoto (@NachoSoto) * `CustomerInfoManager`/`OfferingsManager`: improved display of underlying errors (#1888) via NachoSoto (@NachoSoto) * `Offering`: improved confusing log for `PackageType.custom` (#1884) via NachoSoto (@NachoSoto) * `PurchasesOrchestrator`: don't log warning if `allowSharingAppStoreAccount` setting was never explicitly set (#1885) via NachoSoto (@NachoSoto) * Introduced type-safe `PurchasesError` and fixed some incorrect returned error types (#1879) via NachoSoto (@NachoSoto) * `CustomerInfoManager`: fixed thread-unsafe implementation (#1878) via NachoSoto (@NachoSoto) ### New Features * Disable SK1's `StoreKitWrapper` if SK2 is enabled and available (#1882) via NachoSoto (@NachoSoto) * `Sendable` support (#1795) via NachoSoto (@NachoSoto) ### Other Changes * Renamed `StoreKitWrapper` to `StoreKit1Wrapper` (#1886) via NachoSoto (@NachoSoto) * Enabled `DEAD_CODE_STRIPPING` (#1887) via NachoSoto (@NachoSoto) * `HTTPClient`: added `X-Client-Bundle-ID` and logged on SDK initialization (#1883) via NachoSoto (@NachoSoto) * add link to SDK reference (#1872) via Andy Boedo (@aboedo) * Added `StoreKit2Setting.shouldOnlyUseStoreKit2` (#1881) via NachoSoto (@NachoSoto) * Introduced `TestLogHandler` to simplify how we test logged messages (#1858) via NachoSoto (@NachoSoto) * `Integration Tests`: added test for purchasing `StoreProduct` instead of `Package` (#1875) via NachoSoto (@NachoSoto) * `ErrorUtils`: added test to verify that returned errors can be converted to `ErrorCode` (#1871) via NachoSoto (@NachoSoto)
Fixes CSDK-379 and #1041 (comment)
Main changes:
Sendable
conformances to all types that are thread-safe@unchecked Sendable
for types that the compiler can't enforce, but with documentation as to whyfinal
(note that this doesn't change the API, because none of these wereopen
to begin with)DeviceCache
)For the non-
final
class
es, I've actually managed to compile the SDK with all of them asfinal
andSendable
, to make sure that making them@unchecked Sendable
didn't hide any other issues.Future improvements:
Depends on:
SK2StoreProduct
: conditionally removed@available
workaround #1794Atomic: ExpressibleByNilLiteral
#1804PriceFormatterProvider: Sendable
conformance and fixed thread-safety #1806SystemInfo.finishTransactions
: made thread-safe #1807AttributionFetcherError
insideAttributionFetcher
#1808Purchases.shared
andPurchases.isConfigured
are now thread-safe #1813Atomic: ExpressibleByBooleanLiteral
#1822DeviceCache
:Sendable
conformance and fixed thread-safety #1823CustomerInfo: Sendable
conformance #1824ReceiptParser: Sendable
conformance #1825Offering
/StoreProductType
:Sendable
conformance #1826