Guarantee Singleton Order Of Destruction #1620
Merged
Conversation
This file contains 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
Klaim
force-pushed
the
klaim/fix-singleton
branch
from
e806954 to
d4191e5
Compare
Klaim
force-pushed
the
klaim/fix-singleton
branch
2 times, most recently
from
d283f63 to
07ee63c
Compare
wolfv
reviewed
May 3, 2022
Klaim
force-pushed
the
klaim/fix-singleton
branch
3 times, most recently
from
f3ec7ba to
4e5eaae
Compare
JohanMabille
requested changes
May 9, 2022
In C++ namespace-scope static object are created and destructed in an unspecified order before and after `main()` execution, respectively. The only guarantee is that such objects in the same translation unit shall be constructed in apparition order in the file and destructed in the reverse order. Another guarantee is that local (inside functoins) static object are guaranteed to be created only at the first call to that function, but then there is no guarantee on the destruction order. This is fine until these objects interacts, that is, at least one of these objects have a dependency/usage of another object defined in a different translation unit. We currently have singletons which are implemented as global statics spread through various translation units, and several of these singletons are also accessed through construction and destruction of other singletons. Basically, we have undefined behavior around their creation and destruction, so it is not always visible because often memory looks like valid objects even if it is not. Some recent fixes made this even more visible (which is helpful). This change moves all the singleton object definitions into the same translation unit to begin improving guarantees on their construction and destruction order after `main()` execution.
…rder of execution and destruction.
Currently this can only happen when a singleton is used but it was destroyed.
mamba uses its own (or conda's) json output so libmamba's json output must be cancelled to avoid outputing json twice (and probably different)
Klaim
force-pushed
the
klaim/fix-singleton
branch
from
83e04e4 to
141158a
Compare
|
I just rebased over master. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
In C++ namespace-scope static object are created and destructed in an unspecified order before and after
main()execution, respectively. The only guarantee is that such objects in the same translation unit shall be constructed in apparition order in the file and destructed in the reverse order. Another guarantee is that local (inside functoins) static object are guaranteed to be created only at the first call to that function, but then there is no guarantee on the destruction order.This is fine until these objects interacts, that is, at least one of these objects have a dependency/usage of another object defined in a different translation unit.
We currently have singletons which are implemented as global statics spread through various translation units, and several of these singletons are also accessed through construction and destruction of other singletons. Basically, we have undefined behavior around their creation and destruction, so it is not always visible because often memory looks like valid objects even if it is not. Some recent fixes made this even more visible (which is helpful).
The proposed changings tries to eliminate these issues by: