Hi, Patrick Mihelich wrote: > On Thu, May 6, 2010 at 5:05 PM, Cedric Pradalier > > > 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. The architecture is really easy to use and quite intuitive. This also why I was wondering if a generic message_transport_plugins architecture would make sense. > > - 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(). Thanks for the hint. This makes it work with vanilla ROS (from SVN). Please find the updated version attached. Feel free to include it in the image_transport_plugins if deemed useful. > > - 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 > that > should get you caught up. > This links says me "Not found"... > 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 > infrastructure; big point clouds are the motivating use case. > Similarly, I don't observe a significant performance gain on my laptop either. From htop output, I could make myself believe that 5-10% perf gain are possible, but this is clearly marginal. However, it might be different with more active processes, more cpus, less cpus, more/less rams, bigger use of the network stack, different hardware (gumstix?), so I would tend to put this image_transport_plugins in the common pool, just in case. Best regards, and thanks for the feedback. -- Dr. Cedric Pradalier http://www.asl.ethz.ch/people/cedricp