Issues with RTT 2.0 data flow implementation

I'm playing with the new data flow implementation and bumped into some issues:

1. OutputPort::createConnection does not check if the given input port
is already connected and tries to proceed with the connection anyway.
This leads to corrupted state, double frees etc.
Just adding

diff --git a/src/OutputPort.hpp b/src/OutputPort.hpp
index 6bdea23..91d0106 100644
--- a/src/OutputPort.hpp
+++ b/src/OutputPort.hpp
@@ -141,6 +141,11 @@ namespace RTT
          * policy */
         virtual bool createConnection(base::InputPortInterface&
input_port, internal::ConnPolicy const& policy)
         {
+            if ( input_port.connected() ) {
+                log(Error) << "Can not connect to connected
InputPort." <<endlog();
+                return false;
+            }
+
             // This is the input channel element of the output half
             base::ChannelElementBase* output_half = 0;
             if (input_port.isLocal())

fixes this.

2. in a simple example with one local component with an input port,
and one ControlTaskProxy with an output port, a call to
'local.connectPorts( remote )' causes a runtime exception
'OutputPort::createConnection() is not supported in CORBA port
proxies'. Does this mean that the connection can only be created from
the remote side ? Why isn't this request then forwarded from the proxy
to the remote server in order to make the connection overthere (this
would require access to the server of the local taskcontext)?

3. Similar issues as in 2. with OutputPort::keepLastWrittenValue, and
InputPort::getDataSource.

More to come I guess, but it looks that the CORBA functionality is not
yet fully transparant (can it be ?)

Peter

Issues with RTT 2.0 data flow implementation

On Thu, Aug 27, 2009 at 15:55, Peter Soetens<peter [dot] soetens [..] ...> wrote:
> I'm playing with the new data flow implementation and bumped into some issues:
>
> 1. OutputPort::createConnection does not check if the given input port
> is already connected and tries to proceed with the connection anyway.
> This leads to corrupted state, double frees etc.
> Just adding
> &#10;&gt; diff --git a/src/OutputPort.hpp b/src/OutputPort.hpp&#10;&gt; index 6bdea23..91d0106 100644&#10;&gt; --- a/src/OutputPort.hpp&#10;&gt; +++ b/src/OutputPort.hpp&#10;&gt; @@ -141,6 +141,11 @@ namespace RTT&#10;&gt;          * policy */&#10;&gt;         virtual bool createConnection(base::InputPortInterface&amp;&#10;&gt; input_port, internal::ConnPolicy const&amp; policy)&#10;&gt;         {&#10;&gt; +            if ( input_port.connected() ) {&#10;&gt; +                log(Error) &lt;&lt; &quot;Can not connect to connected&#10;&gt; InputPort.&quot; &lt;&lt;endlog();&#10;&gt; +                return false;&#10;&gt; +            }&#10;&gt; +&#10;&gt;             // This is the input channel element of the output half&#10;&gt;             base::ChannelElementBase* output_half = 0;&#10;&gt;             if (input_port.isLocal())&#10;&gt;
> fixes this.
>
> 2. in a simple example with one local component with an input port,
> and one ControlTaskProxy with an output port, a call to
> 'local.connectPorts( remote )' causes a runtime exception
> 'OutputPort::createConnection() is not supported in CORBA port
> proxies'. Does this mean that the connection can only be created from
> the remote side ? Why isn't this request then forwarded from the proxy
> to the remote server in order to make the connection overthere (this
> would require access to the server of the local taskcontext)?

I fixed this issue with the patch in attachment. The 'ugly' part is
that it adds a pointer to the parent DataFlowInterface for each Port
object (before, the DFI knew about the Port, but not the other way
around). This was needed because in C++, port connections are created
by the port itself, while in CORBA, the connection is made by the
DataFlowInterface object. So if we're connecting two ports in C++, of
which one is remote, we need to get hold of the DataFlowInterface
pointer to setup the CORBA connection.

Any comments appreciated.

>
> 3. Similar issues as in 2. with OutputPort::keepLastWrittenValue, and
> InputPort::getDataSource.

I didn't tackle this one yet.

Peter

Issues with RTT 2.0 data flow implementation

Same patch, but without the whitespace changes.

Peter