Skip to content
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

Replace pointers with values #849

Closed
wants to merge 3 commits into from
Closed

Replace pointers with values #849

wants to merge 3 commits into from

Conversation

ChrisThrasher
Copy link

I found two instances of shared pointers which can be represented as values. Because values have fewer features and few indirections required to use them, they're the better choice in general. I can't think of any reason why these members need to be pointers but if they do, we can still use unique_ptr since shared ownership of these members is not necessary.

@tylerjw
Copy link
Contributor

tylerjw commented Nov 2, 2022

I'm sorry but because of what I know about ClassLoader and how it is unsafe to destroy it; this should stay a shared_ptr.

A better change would be to copy the shared_ptr into a global to make sure it has the same lifetime as the process.

@ChrisThrasher
Copy link
Author

and how it is unsafe to destroy it

I'm unsure what you mean since the shared_ptr will destroy it too.

@tylerjw
Copy link
Contributor

tylerjw commented Nov 2, 2022

If you copy that shared ptr into a global you can extend the lifetime. Making it allocated on the stack gives the user the impression it is safe to delete.

@ChrisThrasher
Copy link
Author

If you copy that shared ptr into a global you can extend the lifetime.

It sounds like you're describing a bug in the status quo of the library. Does this PR exacerbate that problem?

Making it allocated on the stack gives the user the impression it is safe to delete.

This is private data. It's nothing users should be able to observe in the first place.

@destogl
Copy link
Member

destogl commented Nov 3, 2022

This looks good to me. Nevertheless, we are also using loaders in “Resource Manager” so the same changes should also be done there.

Other than that, since we are now resetting the loader object, we have to be sure that objects created by this loader are really independent of it. Do we have a test for it already?

@tylerjw
Copy link
Contributor

tylerjw commented Nov 3, 2022

since we are now resetting the loader object, we have to be sure that objects created by this loader are really independent of it

because of how class_loader works, this is not true. seem my PR here:

ros/class_loader#199

@ChrisThrasher
Copy link
Author

ChrisThrasher commented Nov 3, 2022

This looks good to me. Nevertheless, we are also using loaders in “Resource Manager” so the same changes should also be done there.

Are you talking about the ResourceManager::resource_storage_ data member? That can be converted from a unique_ptr to a value so long as we're willing to move the definition of ResourceStorage from resource_manager.cpp to resource_manager.hpp.

EDIT: I have this implemented locally and the diff is a few hundred lines long just to convert a single unique_ptr<T> to a T. I'm not sure all this is worth removing a single heap allocation.

destogl
destogl previously approved these changes Nov 17, 2022
Copy link
Member

@destogl destogl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be fine. I think we can go with it. It is a bit cleaner.

@ChrisThrasher
Copy link
Author

I see the ABI check is failing which makes sense because changing the layout of a class is a potential ABI break. Does that invalidate this PR or are there options to deal with that?

@bmagyar
Copy link
Member

bmagyar commented Nov 27, 2022

@ChrisThrasher I'd not worry too much about the ABI breaking jobs. Look at the result from this job.

Relevant print is here:

    [INFO] [1669573554.627052878] [test_controller_manager]: Controller manager: reloaded controller libraries for 'controller_interface'
    [INFO] [1669573554.627289276] [test_controller_manager]: Loading controller 'test_controller_name'
    [INFO] [1669573554.632657624] [test_controller_manager]: Controller manager: Stopping all active controllers
    [INFO] [1669573554.632699523] [test_controller_manager]: Empty activate and deactivate list, not requesting switch
    [WARN] [1669573554.632729323] [rcl_lifecycle]: No transition matching 2 found for current state unconfigured
Error: ROR] [1669573554.632740723] []: Unable to start transition 2 from current state unconfigured: Transition is not registered., at ./src/rcl_lifecycle.c:355
    Warning: class_loader::ClassLoader: Cannot unload library /home/runner/work/ros2_control/ros2_control/.work/target_ws/install/controller_manager/lib/libtest_controller.so even though last shared pointer went out of scope. This is because createUnmanagedInstance was used within the scope of this process, perhaps by a different ClassLoader. Library will NOT be closed.
             at line 278 in /opt/ros/rolling/include/class_loader/class_loader/class_loader.hpp

@mergify
Copy link
Contributor

mergify bot commented Dec 20, 2022

This pull request is in conflict. Could you fix it @ChrisThrasher?

@destogl destogl self-requested a review March 21, 2023 14:34
@destogl
Copy link
Member

destogl commented Mar 21, 2023

This causes segmentation fault on runtime-tests - closing.

@destogl destogl closed this Mar 21, 2023
pac48 pushed a commit to pac48/ros2_control that referenced this pull request Jan 26, 2024
* Fix dynamic reconfigure of tolerances

* Fix static cast syntax
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants