[embedded] Default Embedded Concurrency to SWIFT_THREADING_PACKAGE=none

[kubamracek]

The Concurrency runtime (including Embedded Concurrency) can use different underlaying threading API via the SWIFT_THREADING_PACKAGE setting. The different options (C11 threads, PThreads, Darwin, etc.) have a large effect on what dependencies are expected to be provided by the platform. Given that Embedded Swift needs to support a variety of environments, including ones that do not have any threading APIs, the choice of the threading API should probably be a user-configurable option. Until we flesh that out, let's in the meantime default to building Embedded Concurrency as SWIFT_THREADING_PACKAGE=none -- which does not require any threading API (and e.g. locks are simply no-ops) and assumes we have a single-threaded environment.

[rauhul]

Does this imply import _Concurrency would work?

[kubamracek]

import _Concurrency works with a lot of caveats today, see https://github.com/apple/swift/blob/main/test/embedded/concurrency-actors.swift -- the biggest caveat is that Concurrency is only provided for macOS. This change simplifies the way to get import _Concurrency to also work on real embedded setups, but doesn't directly achieve that, there's still more work needed.

[kubamracek]

@swift-ci please test

[rauhul]

interesting, I do really want to explore the space of no-allocation _Concurrency support looks like but thats unrelated to this change

[rauhul]

lgtm, but I also dont understand cmake

[kubamracek]

@swift-ci please test macOS platform

[rokhinip]

Shouldn't this change? We should want to eventually get to being able to specify SWIFT_CONCURRENCY_GLOBAL_EXECUTOR_default = hooked so that SWIFT_CONCURRENCY_GLOBAL_EXECUTOR is set to hooked.

[kubamracek]

Let's do it as a follow-up. If I just naively remove this line, I get...

Undefined symbols for architecture arm64:
  "_swift_reportError", referenced from:
      _swift_task_enqueueGlobal in libswift_Concurrency.a[7](GlobalExecutor.cpp.o)
      swift_task_enqueueGlobalImpl(swift::Job*) in libswift_Concurrency.a[7](GlobalExecutor.cpp.o)
      swift_task_asyncMainDrainQueueImpl() in libswift_Concurrency.a[11](Task.cpp.o)
ld: symbol(s) not found for architecture arm64

...because the hooked version (SWIFT_CONCURRENCY_GLOBAL_EXECUTOR_default = hooked) of Concurrency still brings in the stub implementations from NonDispatchGlobalExecutor.inc, and we should instead really just have these symbols undefined in the runtime, and expect the user to provide them and link them.

[rokhinip]

and we should instead really just have these symbols undefined in the runtime, and expect the user to provide them and link them.

Don't we just want to funnel this to swift_fatal_error which is already hooked?

[kubamracek]

That seems like the wrong solution -- it would certainly work, but we are going to need to keep cutting down dependencies and code in the Embedded Swift Concurrency runtime, and IIUC, in hooked mode, we expect the user/platform to provide swift_task_enqueueGlobal, and therefore the two symbols from the listing above (_swift_task_enqueueGlobal, swift_task_enqueueGlobalImpl ) should really just not be part of the hooked build of Concurrency. Doing that sounds like a double win (besides resolving this undefined symbol problem): (1) less code = better codesize, (2) turns a runtime failure into a link time error.

[ktoso]

I didn't realize we made progress towards SWIFT_THREADING_PACKAGE that's good. I suspect we'd make use of that if we want to do a pure pthreads default executor etc.

[kubamracek]

@swift-ci please test macOS platform

[kubamracek]

@swift-ci please test