Re: Limitations with v2 port implementation

On Wed, Apr 8, 2015 at 1:08 PM, S Roderick <[email protected]> wrote:

> We have ported a large Orocos system from v1 to v2, and identified some
> limitations in the v2 port implementation that we wanted to discuss with
> the community.
>
> v1 ports essentially had one connection object, and thus one value. When
> you connected/read the port, you got the last value that was written. There
> was no concept of “flow” (i.e. when a connection object was updated).
>
> v2 ports have one “object" per input/output connection, and maintain
> potentially different values and flow status per connection (yes, I’m
> simplifying here). So one output port connected to N input ports will have
> N connections, each with potentially different values and flow status.
>
> We’ve run into two issues with v2 ports:
>
> 1) performance when writing to output ports is much slower in v2 than v1,
> as essentially the update occurs to multiple connection objects in v2 (in
> v1 it occurred to one connection object). One of our components has a 450%
> slow down when writing to its eight (8) output ports.
>
> 2) flow status does not cover the use case where you want a single
> connection object, and don’t care when a connection is made nor when a
> value is written (i.e. you don’t care about “flow”). One of our examples
> here is static configuration data (say the name, model or serial number, of
> a device, or a robot’s number of DOF). When the source component is
> configured or started, it writes the appropriate data to the port. If a
> connection is made in the future (say by a GUI, or by a reporting component
> that has dynamically created ports) then v2 ports will not present the
> value that was previously written (I believe as there has been no “flow” of
> data since the connection was made). In this use case, we believe that the
> v1 single-connection-object semantics made more sense as connected peer
> components are only interested in the value, and not when it was written
> nor whether it has been updated (i.e. they don’t care about flow).
>

AFAIK, you can have 2) working in v2 if you create the connection using the
init flag set to true:
http://www.orocos.org/stable/documentation/rtt/v2.x/api/html/classRTT_1_1ConnPolicy.html#a5da839ba68d6ff35ddc44171562ed356
and a have a writer with keepLastWrittenValue to true.

R.


>
> We are *not* saying that the v2 flow status port implementation is bad,
> wrong or incorrect, We're simply saying that it doesn’t deal with some
> valid use cases. The question is, what does the community think, and what
> should be done about it?
>
> Cheers
> Stephen
> --
> Orocos-Dev mailing list
> [email protected]
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>



-- 
Ruben Smits, Roboticist - Founder
+32 479 511 786
Intermodalics - Kapeldreef 60, 3001 Heverlee - BELGIUM
www.intermodalics.eu

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