Add LockIsolated For Recursive Registration#21
Conversation
…nd add recursive registration test
- fix the build error in Package.swift
- use NSRecursiveLock to fix the nonisolated state
sean7218
changed the title
|
|
||
| final class LockIsolated<Value>: @unchecked Sendable { | ||
| private var value: Value | ||
| private let lock = NSRecursiveLock() |
There was a problem hiding this comment.
Let me do some thinking on this. The thing is that OSAllocatedUnfairLock is much faster than NSRecursiveLock , and recursive lock in general are a sign of wrong design on our end. We might want to move things around a bit more instead or go for Swift concurrency.
There was a problem hiding this comment.
Package change is 👍 however, if you want to open that separatedly we can merge that in already
There was a problem hiding this comment.
If performance is a key factor, NSRecursiveLock would be bad choice. It might be an easy way out to just use OSAllocatedUnfairLock with an internal state as to track the lock procession. Since it is only two level recursion for registration during the init request, the subsequent read calls should be just as fast.
Another approach is to use AsyncQueue from SourceKitLSP. The nice thing about this design is the task being run sequentially with Serial: DependencyTracker. That means we are moving into the Swift Concurrency world which has its own added benefits/upkeep
2 participants
Refactor BSPMessageHandler to use LockIsolated for state management and add recursive registration test
- fix the build error in Package.swift
- use NSRecursiveLock to fix the nonisolated state