I'm a bit confused about the Sendable conformance of NSLock. As per the documentation NSLock should conform to Sendable. And indeed, when compiling my code with strict concurrency checking on macOS, no warnings are issued.
However, when compiling on Linux, I get the warning:
warning: static property 'lock' is not concurrency-safe because it is not either conforming to 'Sendable' or isolated to a global actor; this is an error in Swift 6
static private let lock = NSLock()
Is this difference in behavior between macOS and Linux intentional? And should I file this as a bug, or should I find a way of getting rid of the NSLock altogether?
Note: I do think a lock is a valid solution here: I'm protecting a single variable, i.e. code like this:
// NOTE: sessions is a plain old array storing values
lock.lock()
let result = try? sessions.first(where: predicate)
lock.unlock()
return result
I won't say "impossible", but I can't see any way this can deadlock.
I’m afraid you’re out of luck, since this class is from SCF. At this point of time, swift-coreutils-foundation looks pretty much abandoned. Patches are no longer accepted, participation is discouraged and the new hotness seems to be the new Swift-only Foundation that will lack (for some people) essential infrastructure.
@mickeyl@Datagram ah, so that's why when reading the Mutex review I kept thinking: "isn't this what NSLock is doing?"
Let's hope Mutex gets in before/with Swift 6. Otherwise, I need to mark this one nonisolated(unsafe). Not my preference, but NSLock should be safe to use (if it currently is).
FWIW it’s also not the same. NSLock requires a separate allocation. The new non-allocating Mutex type was impossible to implement correctly in Swift 5.x.
Is that actually confirmed policy or just guesswork? The closest thing in the migration plan seems to be "The focus of our development will be on the swift-foundation package", which doesn't sound to me like no bugfixes for SCF, but maybe I'm missing something.
Fwiw, there were a number of PRs merged in the last week, although those are to the package branch and seem to be part of the transition to the new Foundation package. There have also been a number of PRs adding Sendable to some types, most of which were merged.
@Tony_Parker is adding Sendable to NSLock in SCF something that could be accepted at this point in time? I know the long term plan is to address discrepancies between Darwin and other platforms by unifying the implementation, but this particular case seems extra unfortunate due to the urgency implied by the warning.
If you have followed what's going on on the issue tracker, you wouldn't ask this question. There are lots of stale tickets, pull requests, etc. that tell the whole story. Even Apple's own people (doing server things) have stopped trying to get stuff in to fix it for !APPLE platforms – there's a huge meta-issue buried somewhere.
The sheer amount of missing APIs, semantic differences, and sometimes just plain broken implementations has growing so much since mid 2021, it's very sad.
Hmmm. I thought adding Sendable conformance would be as easy as adding it to the NSLock definition. And sure enough I can make the edit. But I wanted to add a quick unit test to verify. However, it seems this is not a "normal" Xcode or SPM project. So maybe somebody else who has experience working in this repo can make the change?
