-
Notifications
You must be signed in to change notification settings - Fork 249
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
[core] Variable deregistry #12554
[core] Variable deregistry #12554
Changes from 3 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -318,6 +318,20 @@ void KratosApplication::RegisterKratosCore() { | |
RegisterVoxelMesherOperation(); | ||
} | ||
|
||
|
||
void KratosApplication::DeregisterVariables() { | ||
const std::string path = "variables."+mApplicationName; | ||
if (Registry::HasItem(path)) { | ||
auto& r_variables = Registry::GetItem(path); | ||
// Iterate over items at path. For each item, remove it from the mappers.all branch too | ||
for (auto i_key = r_variables.KeyConstBegin(); i_key != r_variables.KeyConstEnd(); ++i_key) { | ||
Registry::RemoveItem("variables.all."+*i_key); | ||
} | ||
Registry::RemoveItem(path); | ||
} | ||
} | ||
Comment on lines
+354
to
+364
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This removes the variables registered by the application from the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Please note that the scope of this PR is very narrow (it is intended only for testing, it is not a general "unload application" mechanism). What I am doing here is just ensuring that whoever registered the variable takes care of de-registering it, not ensuring that the kernel remains in a complete state after application de-registry. I understand that this is consistent with what the de-registration logic does for other types of objects. |
||
|
||
|
||
template<class TComponentsContainer> | ||
void KratosApplication::DeregisterComponent(std::string const & rComponentName) { | ||
auto path = std::string(rComponentName)+"."+mApplicationName; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am curious, since registering the same variable from multiple apps causes some seg fault at the moment, shoudn't we throw an error if it exists, rather than checking the type?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that Kratos should be able to support registering the same variable from multiple applications, as long as the type is the same. Using the registry in this way would be a step in that direction, since users of the registry are sure to always get the same thing when retrieving a given variable (something that is not so clear with components if Kratos allows overwriting variables as is happening now).