Open doudou opened 4 years ago
I think this is "by design": The data sample is not stored separately in data elements and buffers, only in the OutputPort<T>
instance. setDataSample()
is almost equivalent to write()
in the way it is pushed through the channel pipeline. The only difference is that buffers or lock-free data objects use the sample to reinitialize all their internal storage, and that it should not trigger a NewData
read or port events on the output side of the channel (the InputPort
).
The exact behavior of a read()
depends on the type of connection (data/buffer, locked or lock-free).
Is the sample returned by the input port with FlowStatus
NewData
? If yes that would be a bug indeed.
Do you read with copy_old_data
set to true
(the default)?
I remember having seen this problem a while ago, but appeared to be fixed (?)
It might be with OldData
. I consider it a bug either way, maybe an "intended behavior" because of how things have been implemented, but having an OldData that is an invalid sample (because only for initialization) is pretty bad.
While integrating a component that would setDataSample its outputs in configureHook, I noticed that the sample I gave to setDataSample would end up read by the other side.
(for reference: https://github.com/rock-control/control-orogen-motor_controller/commit/dd14ca63e5b37d393a61f997f5e188e87fa1b9b6)
In this particular instance, I am fairly sure that setDataSample is the problem - even though I haven't debugged it fully:
The same caveat than in #318 applies here: it might be an old already fixed bug, due to the fact that Rock is stuck to an old RTT commit because of #302