Uninterupted output of destructors of ros-nodes [closed]

edit

I understand that you are doing this in a ROS context/application, but your question is actually not ROS-specific. It seems to be about the order in which destructors are called and how the system handles thread/process scheduling. That makes it a question off-topic for this forum.

I would suggest you ask this on a more appropriate forum, such as one about C++ programming.

@gvdhoorn I see what you are saying, but I feel like it's a problem exclusive to the way that ROS is handling multiple nodes. Seems to me, like ROS is using a different thread for each node. I used to think, that it's only going to make benefit of multithreading when you specifically declare async spinners.

Nodes are mapped onto processes. Nodelets use threads.

I may have misunderstood you though: are you using actual object instances for each callback (or multiple callbacks)?

I am using multiple nodes each of which has a main() function which will create an instance of a class (different class for each node) which will trigger multiple callbacks.
What are nodelets though, and what's the difference between nodelets and nodes?

So you basically have something like:

main()
{
  MyRosNode node;
  ros::spin();
}

where MyRosNode creates a nr of Subscribers and registers class methods as callbacks?

And each of the MyRosNode classes has a dtor that has a nr of std::couts in them?

@gvdhoorn Exactly. Sorry for not making that more clear. Sometimes I'm a little puzzled about what is the clearest way to make people understand, what I'm doing.
In case that matters: Before MyRosNode node; I will also do

ros::init(argc,argv, "MyRosNode");
ros::NodeHandle n;

And you have multiple nodes that follow this structure?

In that case your node is just a process. Not a thread.

Callbacks could be handled multithreaded, but only if you'd create a multi-threaded or async spinner.

But that will only influence the way callback code is executed. Not the dtors afaik.

@gvdhoorn Yes, I currently have three nodes following this structure. But does that mean the only thing that I would have to change in my code, to profit from multiple CPU cores and multithreading is to create a multi-threaded or async spinner in each node in the main function?