Re: Updated dataflow semantics for RTT

On Fri, Sep 25, 2015 at 6:24 PM, Sylvain Joyeux <[email protected]> wrote:
>
> Hi Johannes
>
> > To me, this calls for having different behaviours for data object and
> > buffer objects: one data object per input port and one buffer per
> > channel. In all cases. It would actually both fix the bug you describe
> > above *and* keep mixed-policy behaviour as well as keep buffer setup
> > feasible (since sizing buffers is meaningful only on a per-connection
> > basis).
>
> I did not get any comment from you about this ... It concerns me as my
> current understanding is that by fixing RTT for your use case, you
> would basically fundamentally break it for mine ...

It doesn't fix the out-of-order bug for the buffer-per-channel case.
You can still starve
a certain channel and get old data much later. That's why we propose
to change the
default. This starving already happens in very simple/clean setups,
unless you start
to round-robin all the channels. But again, this does not prevent
out-of-order arrivals.

I prefer the proposed solution since the default policy leads to a
much more predictable
data flow. For appropriately sizing buffers for push channels in
multi-rate component systems,
we thought about it to specify on the input port level the buffer size
(there is already a
default conn policy for each input port). A code generator like orogen
could easily calculate
the largest buffer size required between components and inform the
input port, or stick to
pull connections.

I would definately not 'imply' different behaviours depending on
buffer/data. After
all, a data object is just a circular buffer of size 1.

Peter
-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev