On Thu, May 6, 2010 at 5:05 PM, Cedric Pradalier <span dir="ltr"><<a href="mailto:cedric.pradalier@mavt.ethz.ch" target="_blank">cedric.pradalier@mavt.ethz.ch</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


I've just written a small shared-memory based image_transport_plugin using boost::interprocess<br></blockquote><div><br>Cool! I think you're the first person outside WG to write an image_transport plugin, so any feedback about the architecture is welcome.<br>

<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
- 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?<br>

</blockquote><div><br>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().<br>

<br>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.<br>

<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
- 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...<br>

</blockquote><div><br>Shared memory transport is a common feature request. There's a long discussion of the issues at <a href="http://ros-users.122217.n3.nabble.com/Shared-memory-transport-using-C-in-ROS-td414682.html%20">http://ros-users.122217.n3.nabble.com/Shared-memory-transport-using-C-in-ROS-td414682.html </a>that should get you caught up.<br>
<br>Short version:<br> * 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.<br> * Storing the message objects themselves in shared memory could be a win, but gets very complicated to implement.<br>
 * We've focused on optimizing intra-process (no-copy) message passing and are developing the <a href="http://www.ros.org/wiki/nodelet">nodelet</a> infrastructure; big point clouds are the motivating use case.<br><br>
Patrick<br></div></div>