-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[Threading][TSan] Fix TSan errors from lazy init on Linux. #67017
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
[Threading][TSan] Fix TSan errors from lazy init on Linux. #67017
Conversation
Move the TSan functionality from Concurrency into Threading. Use it in the Linux ulock implementation so that TSan knows about ulock and will tolerate the newer swift_once implementation that uses it. This should also slightly improve the performance of Concurrency, since the tsan tests will be inlined rather than it always doing a subroutine call. rdar://110665213
We shouldn't be using stat() or dlsym() in the freestanding runtime. rdar://111214571 rdar://106555012
Explanation: The Linux implementation of |
@swift-ci Please test |
preset=stdlib_S_standalone_minimal_macho_x86_64,build,test |
See also #66877, which is the 5.9 cherry pick. |
@kubamracek I assume the issue here with the freestanding preset isn't one I've created by fixing the TSan problem in 5.8? Just wanted to get confirmation before I ask for branch manager approval (this is for a Linux point release). |
Apparently the bot is misconfigured and is downloading the wrong toolchain, which is why the standalone preset failed. |
Move the TSan functionality from Concurrency into Threading. Use it in the Linux ulock implementation so that TSan knows about ulock and will tolerate the newer swift_once implementation that uses it.
This should also slightly improve the performance of Concurrency, since the tsan tests will be inlined rather than it always doing a subroutine call.
rdar://110665213