Re: Limitations with v2 port implementation

On Wed, 8 Apr 2015, S Roderick 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).
>
> 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?

My position on this is that communication policies should be fully
decoupled from the container component policies. In other words:
- choose whatever communication middleware and p2p architecture and
   "flow" policy that your application need;
- let the container component be triggered by any input on any of its ports;
- introduce a "scheduler" that decides how to react to that trigger;
- let the trigger trigger the computational component(s) inside the
   container that are involved in the communication.
This is neither v1 nor v2...

> Cheers
> Stephen

Herman

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