-
Notifications
You must be signed in to change notification settings - Fork 285
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
(chore): Use Native swift Atomics #1969
base: main
Are you sure you want to change the base?
(chore): Use Native swift Atomics #1969
Conversation
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.
Thank you @mustiikhalil 🙏🏽
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.
Thanks for the update. I have two high-level comments:
- Should we just use
sequentiallyConsistent
as the ordering? As far as I can tell, the currentreleasing
andacquiring
produce the same semantics and I findsequentiallyConsistent
easier to reason about. Or am I missing something. - I think some of the
Atomic<Int32>
andAtomic<UInt32>
can now becomeAtomic<Int>
if that simplified their usage. They were onlyInt32
andUInt32
because of C interop.
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.
Very nice. I noticed one small mistake while looking through again, otherwise everything is great!
@@ -216,7 +217,7 @@ package final class TestSourceKitLSPClient: MessageHandler, Sendable { | |||
// It's really unfortunate that there are no async deinits. If we had async | |||
// deinits, we could await the sending of a ShutdownRequest. | |||
let sema = DispatchSemaphore(value: 0) | |||
server.handle(ShutdownRequest(), id: .number(Int(nextRequestID.fetchAndIncrement()))) { result in | |||
server.handle(ShutdownRequest(), id: .number(Int(nextRequestID.add(1, ordering: .sequentiallyConsistent).newValue))) { result in |
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.
server.handle(ShutdownRequest(), id: .number(Int(nextRequestID.add(1, ordering: .sequentiallyConsistent).newValue))) { result in | |
server.handle(ShutdownRequest(), id: .number(Int(nextRequestID.add(1, ordering: .sequentiallyConsistent).oldValue))) { result in |
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.
and I am assuming that when subtracting
or adding
in the following places its the new value that we need and not the old one.
let count = bytesCollected.add(bytes.count, ordering: .sequentiallyConsistent).newValue
var progress = Double(count) / Double(expectedLogSize)
let count = pendingUnitCount.subtract(count, ordering: .sequentiallyConsistent).newValue
if count == 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.
Yes, that’s correct. It’s just this case where we want to use the oldValue
because nextRequestID
is the next request ID that hasn’t been used yet. We use nextRequestID
with oldValue
in other places as well.
d53797e
to
7fb0adb
Compare
@swift-ci Please test |
Replaces the usage of CAtomics with the native Atomics from the swift library and bumps the development platform to macOS 15
Replacing the usage of Int32, and UInt32 with Int since the previous was only used because of c bridging Uses .sequentiallyConsistent for all loading and storing methods
7fb0adb
to
df47d38
Compare
The Ci failed because of a newly merged commit that uses the AtomicUint32 |
Thanks for the update @mustiikhalil @swift-ci Please test |
@swift-ci Please test Windows |
@swift-ci Please test |
The following PR addresses the following:
Closes #1949