chore: Elide mutex variable from Lock class when it is unused#3483
Merged
Lukasa merged 1 commit intoapple:mainfrom Jan 22, 2026
Merged
chore: Elide mutex variable from Lock class when it is unused#3483Lukasa merged 1 commit intoapple:mainfrom
Lukasa merged 1 commit intoapple:mainfrom
Conversation
633c201 to
7b50463
Compare
… handled compiler conditions conditions. Previously, the allocation would essentially be an unused allocation.
7b50463 to
fb6db90
Compare
Contributor
Author
|
@Lukasa Thanks for reviewing this! I rebased this on the latest |
This was referenced Feb 3, 2026
kukushechkin
pushed a commit
to apple/swift-log
that referenced
this pull request
Feb 12, 2026
…408) Ports changes to `Lock` from swift-nio to swift-log. ### Motivation: The copy-paste of `Lock` in swift-log should be updated with changes from swift-nio. ### Modifications: - Rolls back changed [made previously for FreeBSD](https://github.com/apple/swift-log/pull/387/changes#diff-7b1bd45403dd1a7418287bd60682bf05ba2e4bf75dca1c0ca55a86d0477c9af5L73) in favor of a consolidated implementation in swift-nio that will be in place once apple/swift-nio#3494 merges. @kkebo Please confirm this works. After both of our PR's merge, swift-log and swift-nio will have the same implementation as far as FreeBSD is concerned. - Brought the following recent changes from swift-nio over to swift-log: - apple/swift-nio#3482 - apple/swift-nio#3480 - apple/swift-nio#3483 - Removed stale `// SRWLOCK does not need to be free'd` comment. ### Result: `Lock` implementation will have the same implementation as swift-nio (assuming apple/swift-nio#3494 merges).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation:
In reviewing a copy of this file in swift-log, @czechboy0 noticed that the
mutexvariable is essentially unused and unnecessarily allocated for certain conditions. It is possible the compiler elided usage. But given the unconditional variable reference in thedeinit, the compiler may not be able to.This change ensures the
mutexproperty is completely elided except in the conditions where it is used.Modifications:
mutexproperty for conditions where it would be unused.deinitto avoid referencingmutexunless it is compiled into theLockclassResult:
The
mutexproperty is no longer allocated or even compiled into theLockclass for unsupported configurations. All unit tests and checks pass.Research:
The
deinitused to have a blanket call tomutex.deallocate(). This has been moved into the platform-specific checks within thedeinit. This allows complete elision of themutexproperty altogether. The_runtime(_multithreaded)condition appears to be rooted to this implementation. Diving deeper, all operating systems in this list except for UnknownOS and WASI result in_runtime(_multithreaded)returning true. That means thatOpenBSD(and many other operating systems besides windows) were almost certainly using the#elseif (compiler(<6.1) && !os(WASI)) || (compiler(>=6.1) && _runtime(_multithreaded))condition in thedeinit. In conclusion, movingmutex.deallocate()up into the conditional clauses insidedeinitshould be identical to the previous implementation for all operating systems exceptllvm::Triple::UnknownOS. Andllvm::Triple::UnknownOSis likely not to have every compiled anyways due to the check on line 32.So in summary, it is expected that this clean up will compile identical to the previous implementation for all platforms except WASI platforms that don't have pthread support. For non-pthread WASI platforms, the unused
mutexis properly elided from compilation altogether.Testing Done: