Sendable conformance of NSLock on Linux

Hi everyone,

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
let result = try? sessions.first(where: predicate)
return result

I won't say "impossible", but I can't see any way this can deadlock.

KR Maarten

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.

1 Like

The accepted SE-0433 Mutex will be added of the standard library and available on macOS, Linux and Windows.

1 Like

@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).

1 Like

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.

Well, impossible to implement optimally.

1 Like

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.


@ Tony_Parker is adding Sendable to NSLock in SCF something that could be accepted at this point in time?

That would indeed be welcome.

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.

Yes, we can add Sendable to NSLock. Please open a PR and we'll get it merged.


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?

FWIW: I did create an issue on the Apple repo.

In this case I think it's ok to go without the unit test. There's no runtime behavior to verify in reality - it's just an annotation for the compiler.

1 Like

So, I opened a PR: add Sendable conformance to NSLock by maartene · Pull Request #4944 · apple/swift-corelibs-foundation · GitHub

Note: I am unable to build this project, so I'll have to rely on CI to give feedback about whether this is a working solution.

Hmmm. The CI tests fail on the macOS platform. :slightly_frowning_face:

Though it seems the macOS CI tests have been [failing for some time]( [Pull Request] Swift Foundation Test macOS Build time trend [Jenkins]): IIUC the last successful one was from [Jan 5th]( [Pull Request] Swift Foundation Test macOS #354 [Jenkins]).

PR was merged into main last night. So Sendable conformance will come to NSLock. :tada: