sample given to setDataSample seem to sometimes "leak" to the other side

[doudou]

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 issue was happenning consistently at first start of the component. However, removing setDataSample made it disappear.
• the sample received on the other side has a non-empty 'names' field, while the names vector is empty for all other samples sent by the component

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

[meyerj]

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)?

[ahoarau]

I remember having seen this problem a while ago, but appeared to be fixed (?)

[doudou]

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.