-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[Build][Runtime] Add a new threading library. #42447
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
Conversation
f0a627b
to
0e9c955
Compare
d6495f8
to
56c7210
Compare
c09e832
to
054b957
Compare
@swift-ci Please test |
I haven't taken a deep dive yet, but I'm wondering about the necessity of the platform-specific implementations. Since Linux and Windows both have C++'s Given Swift's lack of official support for platforms other than Darwin and Linux, it seems to me like we should lean on the STL as much as possible rather than rolling our own equivalent implementations. |
I've updated the comment at the top with some notes on the changes that are hopefully useful for reviewers. |
After rebasing, a few things broke. Fix them. rdar://90776105
…d special. While most systems aren't going to have their stack bottom at zero, using llvm::Optional<> here is cleaner. rdar://90776105
@swift-ci Please test |
@al45tair can you make sure the standalone minimal test still passes? I think it uses the single threaded flag. |
preset=stdlib_S_standalone_minimal_macho_x86_64,build,test |
Hmmm. "Can't find CMake" seems like not my fault. I'll give it another go, in case it's just a host issue, then go look what the problem might be. |
preset=stdlib_S_standalone_minimal_macho_x86_64,build,test |
LGTM (sorry, it took a while to go over the large diff). Given that the PR testing for "stdlib minimal" seems to have some infrastructure issues, I am going to run the "preset testing" locally to ensure we're not breaking it, I'll report back. |
When we're building static libraries, we don't need to include the threading objects in both Concurrency and Core, and we also don't need two copies of the threading library's fatal error handler. rdar://90776105
@swift-ci Please test |
preset=stdlib_S_standalone_minimal_macho_x86_64,build,test |
This passed local testing of the minimal preset just now, FWIW:
|
Looks like preset testing in CI is still broken. |
@shahmishal can you prioritize fixing preset testing in CI? We need it to work to test PRs like this? |
If the preset testing worked locally... I am happy. |
@swift-ci Please test Linux platform |
@swift-ci Please test |
`SWIFT_BUILD_STATIC_STDLIB` is not mutually exclusive with `SWIFT_BUILD_DYNAMIC_STDLIB`, and Linux sets both, so we can't use `SWIFT_BUILD_STATIC_STDLIB` to conditionalise things. The linker error about duplicate definitions for the threading error handler was happening because we were forced to include the object containing that symbol; moving it to another object should fix that. And it turns out there's a way to get CMake to include the threading object library only when building a shared object, so use that too. rdar://90776105
@swift-ci Please test |
The Linux issue has to do with the fact that I'd not appreciated that Local testing of the preset passes still:
|
Thank you @al45tair for your great work!! The |
@kateinoigakukun Glad to know it's helpful. It's been reverted for now because of a few CI failures (the Linux problem you sent a PR for, plus some simulator related problems). I'll get it re-submitted ASAP. |
A fair bit of this is really shuffling things around — that's largely true for the
swift::Mutex
, which was an existing thing.swift::Thread
is really a placeholder for when we need more support — right now, we don't need any of the functionality that e.g.std::thread
has, but we do need some functionality it doesn't have. It's also desirable to be able to choose which threading package to use, especially for embedded use or for testing purposes, and if we make everything defer to the C++ library we'll only be able to use whatever the C++ library is using.The main new things are:
#include
s of implementation files in order to bring them in to the standard library or concurrency code.swift::Lazy
now usesswift::once
rather than having its own implementation that uses a macro.swift::once
implementations for Linux and Windows that should be somewhat faster on those platforms.