Ask Your Question
1

how to receive non-const shared_ptr without copies when publishing between nodelets? [closed]

asked 2014-10-23 16:29:27 -0500

Matias gravatar image

updated 2014-10-24 09:07:26 -0500

I have several nodelets sharing a C++ class adapted to ROS message_traits. I'm publishing a non-const shared_ptr to other nodelets. The nodelets expecting a ConstPtr on the callback receive the same data (the .get() method of the shared_ptr returns the same number from sender to receivers). However, on another I'm receiving a non-const shared_ptr as well and in this case a copy of the object is made (I can confirm this several ways, .get() also returns a different number).

I understand that problems could arise if an object is modified on the receiver and the sender does not expect this, but I hoped this would be a decision left to the user and not enforced by performing a copy in this case. Since I publish a non-const object, I expect to be able to receive a non-const object without any intermediate copies. My code ensures that modifying things on the sender will not break things on receiver in this case.

Is it possible to avoid the copy?

UPDATE: I've looked a bit more into the issue and I'm starting to believe there is a bug.

The matter occurs when publishing a non-const shared_ptr and I have one non-const subscriber AND another subscriber (be it const or non-const). If I have a single non-const, two non-const or one const subscriber, it works. However, having one non-const with any others trigger the problem. Note that it appears the non-const subscribers receive the copy and this only happens after a second sending of the message. It all leads me to believe that, whenever a non-const subscriber's callback is called, for some reason, an internal const version of the message is stored somewhere in the ROS pipeline. Afterwards, any other invoked non-const callback sees that since it has an internal const ptr stored, it needs to perform a copy to offer the non-const version. However, it appears as a contradiction since I can at least once receive the non-const version so it appears the behavior is unintended.

edit retag flag offensive reopen merge delete

Closed for the following reason the question is answered, right answer was accepted by Matias
close date 2015-06-26 17:24:11.484695

1 Answer

Sort by ยป oldest newest most voted
3

answered 2014-10-24 12:45:10 -0500

Dirk Thomas gravatar image

This is not a bug but the only reasonable behavior of the API. If your non-const subscriber would receive a reference (no copy) of the original message it can modify the message instance which would effect all other subscribers. Even worst since the order of the subscriber callbacks is not deterministic the overall system behavior would be non-deterministic.

From the perspective of another const subscriber the message instance can change will it is being processed in the callback.

So if you do want to use zero copy your subscriber must specify const in the callback signature.

edit flag offensive delete link more

Comments

Please read https://github.com/ros/roscpp_core/is... for a more detailed explanation.

Dirk Thomas gravatar imageDirk Thomas ( 2014-10-24 13:44:53 -0500 )edit
1

Ok! Sorry again for the mixup! What do you think would be then the way to share non-const data between nodelets? Being threads I could share global data, but I was hoping to use some ROS standard way. I was hoping that sharing shared_ptr as messages would be the correct way.

Matias gravatar imageMatias ( 2014-10-24 13:54:22 -0500 )edit
1

ROS does not provide you with an atomic way to share pointers in a bidirectional way. You should consider using two topics: once from A to B and the other from B to A and use const in the subscriber signature to avoid copies.

Dirk Thomas gravatar imageDirk Thomas ( 2014-10-24 15:04:03 -0500 )edit

And if I want the receiver to be able to modify the sender's instance? (ie. to receive a non-const ptr)? Can I avoid the copy somehow?

Matias gravatar imageMatias ( 2014-10-24 15:30:41 -0500 )edit

No, that is not possible for the state reasons.

Dirk Thomas gravatar imageDirk Thomas ( 2014-10-24 16:09:44 -0500 )edit

Question Tools

1 follower

Stats

Asked: 2014-10-23 16:29:27 -0500

Seen: 749 times

Last updated: Oct 24 '14