Skip to content
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.

Sign up for GitHub

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

Jump to bottom

LockIsolated.withValue closure should be sendable #13

Merged
merged 1 commit into from
Nov 8, 2023
Merged

LockIsolated.withValue closure should be sendable #13

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
8 changes: 5 additions & 3 deletions Sources/ConcurrencyExtras/LockIsolated.swift
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -39,7 +39,7 @@ public final class LockIsolated<Value>: @unchecked Sendable {
/// - Parameter operation: An operation to be performed on the the underlying value with a lock.
/// - Returns: The result of the operation.
public func withValue<T: Sendable>(
_ operation: (inout Value) throws -> T
_ operation: @Sendable (inout Value) throws -> T
) rethrows -> T {
try self.lock.sync {
var value = self._value
Expand Down Expand Up @@ -93,15 +93,17 @@ extension LockIsolated where Value: Sendable {
}
}

@available(*, deprecated, message: "Lock isolated values should not be equatable")
extension LockIsolated: Equatable where Value: Equatable {
public static func == (lhs: LockIsolated, rhs: LockIsolated) -> Bool {
lhs.withValue { lhsValue in rhs.withValue { rhsValue in lhsValue == rhsValue } }
lhs.value == rhs.value
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line (and the hashable line) do emit warnings in strict concurrency, so we should have a timetable for removal or consider making them unavailable, though that is a breaking change.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there new Sendability issues if you continue using withValue here?

Worth mentioning that OSAllocatedUnfairLock has a similar API where withLock takes a Sendable closure but there's also a withLockUnchecked that doesn't enforce Sendability. Would be cleaner ergonomically than requiring the use of UncheckedSendable, and you could use the unchecked variant here and in the Hashable impl (assuming you want to keep the conformances.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kabiroberai Yup, now that withValue is sendable we can't traffic the lhsValue into the closure unless it's sendable.

withLockUnchecked is an interesting idea, though I still think equatability and hashability should probably be on the chopping block since they are simple operations that should not block/lock.

}
}

@available(*, deprecated, message: "Lock isolated values should not be hashable")
extension LockIsolated: Hashable where Value: Hashable {
public func hash(into hasher: inout Hasher) {
self.withValue { hasher.combine($0) }
hasher.combine(self.value)
}
}

Expand Down