Hi Josh, I was not clear. I agree with you, and I'm aware data corruption could easily make the node crash, especially if the size of an array is read incorrectly for instance. At this stage, I'm still assuming that the structure size does not change during operation, which I agree is a very dangerous assumption. I would tend to accept that individual data (pixels, laser range) could be corrupted. As this is leaving too much possibility for errors, the next stage would be to have a table of shared mutex (POSIX mutex would do the job), associated with each object in the memory block. We had that mechanism implemented in DDX, so I could start from there but I still have to find out how to make it in boost. I'll invest the time when I can see that someone has an interest and a use-case for this form of shared memory transport. On 12/02/10 23:10, Josh Faust wrote: > > > On Thu, Dec 2, 2010 at 1:49 PM, Cedric Pradalier > > > wrote: > > Good points. > > Regarding data corruption, I'd would tend to consider it as an > accepted risk for this type of transport, but I agree the plugin > should be more resilient to this possibility. > > > Absolutely not. Corruption here can easily cause the node to crash. > > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > -- Dr. Cedric Pradalier http://www.asl.ethz.ch/people/cedricp