[ros-users] Shared memory image plugin

[Patrick Mihelich]

On Thu, May 6, 2010 at 5:05 PM, Cedric Pradalier <
cedric.pradalier at mavt.ethz.ch> wrote:

> I've just written a small shared-memory based image_transport_plugin using
> boost::interprocess
>

Cool! I think you're the first person outside WG to write an image_transport
plugin, so any feedback about the architecture is welcome.

- First, I don't see how to write it efficiently while having the publish
> function const in image_transport/publisher.h. I currently wait to receive
> the first image to allocate the shared memory segment, and as far as I could
> tell, I can only do it in the publish function of the plugin, so this has to
> be non-const. Any reason why it would have to be const? Or any hint on how
> to achieve the same result while having the function const?
>

publish() is const to match the API of ros::Publisher, but you can still do
what you want. You just need to mark the class members that change with the
"mutable" keyword. See TheoraPublisher in theora_image_transport for an
example; it similarly does some setup in publish().

As to why this makes sense, in C++ const is a slightly subjective term; you
can distinguish between "physical constness" (no bits of object state
change) and "logical constness" (object state changes, but this is not
apparent to the user). For an example of the latter, say we have a class
member foo() that performs some expensive computation and caches the result
so that subsequent calls to foo() return immediately. The caching behavior
is an optimization with no effect on the result. Since the cached value may
change, foo() is not physically const, but it can be considered logically
const. C++ has the mutable keyword specifically to support this sort of
thing.

- Second, as it is written now, the plugin does not care at all that the
> object it manipulates are images (it cares that the object are
> constant/bounded size though). So would it be possible to extend/convert the
> image_transport plugin architecture, to a generic message_transport plugin
> architecture? I think sharedmem transfer would be particularly suitable for
> big point clouds...
>

Shared memory transport is a common feature request. There's a long
discussion of the issues at
http://ros-users.122217.n3.nabble.com/Shared-memory-transport-using-C-in-ROS-td414682.html
<http://ros-users.122217.n3.nabble.com/Shared-memory-transport-using-C-in-ROS-td414682.html%20>that
should get you caught up.

Short version:
 * We haven't found shared memory transport of serialized data to be a
significant improvement versus TCP over loopback, but are interested in
evidence to the contrary.
 * Storing the message objects themselves in shared memory could be a win,
but gets very complicated to implement.
 * We've focused on optimizing intra-process (no-copy) message passing and
are developing the nodelet <http://www.ros.org/wiki/nodelet> infrastructure;
big point clouds are the motivating use case.

Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100506/3b15ed80/attachment-0003.html>