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
> <cedric.pradalier@mavt.ethz.ch <mailto:cedric.pradalier@mavt.ethz.ch>>
> 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
(text/plain)