On Fri, Mar 14, 2008 at 08:22:03AM +0100, Herman Bruyninckx wrote:
> As soon as you have two processes, the components running in them _are_
> "remote" (in the sense of having separated memory spaces; CORBA makes it
> irrelevant whether they are on the same computer or not). Or do you
> have another interpretation of remote?
No. There are three processes: two processes and are orocos components
executing two task contexts T1 and T2 and one is a ruby script (no
orocos thing).

What I want is that the ruby script connects a porti from T1 on a port
from T2.

Sylvain

Thanks for the input. I digged into the dataflow/corba implementation
and I fail to see how it is supposed to work:

• CorbaPort is neither a DataPort nor a BufferPort object and the

  connection factory stuff expects one or the other. Net result:
  one cannot use a connection factory to connect a local porti with a
  remote one.

• when a connection is created, the remote side is never notified of the

  it. I'm working with buffer ports. I tried to use connectPorts(),
  which "works" (i.e. does not return any error), but the connection is
  definitely not passing any data. If I do (assuming a producer task
  context and a receiver one)

    receiver.connectPorts(producer)

  then the receiver thinks its data port is actually connected, but not
  the producer, in which case data is never sent. If I do the other way
  around:

    producer.connectPorts(receiver)

  then the producer actually expects a connection to exist, one can push
  to the data port, but the data never gets to the other side and the
  buffer port is filled.

  Data ports behave in exactly the same way ...
  
  I'm using 1.4.0. Should I try svn trunk or the svn 1.4 branch ? Is
  there any meaningful update for corba support in those ?

Best regards,
Sylvain

On Friday 14 March 2008 17:41:19 Sylvain Joyeux wrote:
> Thanks for the input. I digged into the dataflow/corba implementation
> and I fail to see how it is supposed to work:
>
> * CorbaPort is neither a DataPort nor a BufferPort object and the
> connection factory stuff expects one or the other. Net result:
> one cannot use a connection factory to connect a local porti with a
> remote one.

That is not correct. The ConnectionFactory will detect if the PortInterface
uses a transport protocol, if so, it asks the protocol to setup a connection,
instead of asking it the port directly. Hence a CORBA connection is created
when a CorbaPort is used.

>
> * when a connection is created, the remote side is never notified of the
> it. I'm working with buffer ports. I tried to use connectPorts(),
> which "works" (i.e. does not return any error), but the connection is
> definitely not passing any data. If I do (assuming a producer task
> context and a receiver one)
>
> receiver.connectPorts(producer)

Is this using the IDL interface with my patch?

Normally, when a CORBA connection is created, the remote end sets up a
connection with one port, and so does the local end. Both connections share
the same buffer or data object, accessible locally or from the network. As
far is I know, the connection needs to be disabled on both sides if you want
to break up the CORBA connection.

CORBA ports/ connectPorts do work at the PMA using the C++ layer.
I'll add a CORBA ports unit test as well to see if I can reproduce your
problems.

>
> then the receiver thinks its data port is actually connected, but not
> the producer, in which case data is never sent. If I do the other way
> around:
>
> producer.connectPorts(receiver)
>
> then the producer actually expects a connection to exist, one can push
> to the data port, but the data never gets to the other side and the
> buffer port is filled.

ok. Clearly a bug.

>
> Data ports behave in exactly the same way ...

Corba Data ports have been used in real applications... it seems you're using
some other code path...

>
> I'm using 1.4.0. Should I try svn trunk or the svn 1.4 branch ? Is
> there any meaningful update for corba support in those ?

The svn rtt-1.4 branch has the latest backwards compatible fixes, but your
CORBA enhancements will be trunk/rtt only. I've just located two possible
bugs in the ConnectionFactory which may be part of your problem.

I have submitted bug reports and will commit them on trunk asap, and add the
unit tests as well.

Peter

On Mon, Mar 17, 2008 at 10:26:56AM +0100, Peter Soetens wrote:
> > * when a connection is created, the remote side is never notified of the
> > it. I'm working with buffer ports. I tried to use connectPorts(),
> > which "works" (i.e. does not return any error), but the connection is
> > definitely not passing any data. If I do (assuming a producer task
> > context and a receiver one)
> >
> > receiver.connectPorts(producer)
>
> Is this using the IDL interface with my patch?

OK. RTT does not end in the code path it is supposed to. I end up having
a warning at ConnectionFactory.hpp:186 while it should have went into
the conn_buffer != NULL case ... Strange.

Your patch has a bug by the way: the "return ci->connected()" statement
crashes if ci is NULL.

> I have submitted bug reports and will commit them on trunk asap, and add the
> unit tests as well.
OK. Thanks for the help. I'll compile and try trunk ASAP.

Sylvain

On Monday 17 March 2008 11:03:12 Sylvain Joyeux wrote:
> On Mon, Mar 17, 2008 at 10:26:56AM +0100, Peter Soetens wrote:
> > > * when a connection is created, the remote side is never notified of
> > > the it. I'm working with buffer ports. I tried to use connectPorts(),
> > > which "works" (i.e. does not return any error), but the connection is
> > > definitely not passing any data. If I do (assuming a producer task
> > > context and a receiver one)
> > >
> > > receiver.connectPorts(producer)
> >
> > Is this using the IDL interface with my patch?
>
> OK. RTT does not end in the code path it is supposed to. I end up having
> a warning at ConnectionFactory.hpp:186 while it should have went into
> the conn_buffer != NULL case ... Strange.

What is the exact warning ? What data are you trying to transport ? I assumed
you used 'double' or similar ? Could you set:

export ORO_LOGLEVEL=7
run your application and send the contents of orocos.log ?

>
> Your patch has a bug by the way: the "return ci->connected()" statement
> crashes if ci is NULL.

Thanks for reporting. Fixed now.

>
> > I have submitted bug reports and will commit them on trunk asap, and add
> > the unit tests as well.
>
> OK. Thanks for the help. I'll compile and try trunk ASAP.

You need to recompile your application as well as trunk is not binary
compatible with RTT 1.4.

Peter

I finally found the main problem: serverProtocol is not reimplemented in
CorbaPort, which leads the connection factory to believe that the porti
is actually not remote ...

Sylvain

On Monday 17 March 2008 14:31:41 Sylvain Joyeux wrote:
> I finally found the main problem: serverProtocol is not reimplemented in
> CorbaPort, which leads the connection factory to believe that the porti
> is actually not remote ...

When I read this, I knew you were right but I just couldn't believe it :-]

Thanks for this wonderful work of code review... does it work now?

So far for the "Corba Data ports have been used in real applications... it
seems you're using some other code path...". Well you did. I just informed
and found out that the other applications only accessed the ports from a
Python script, and did not create a connection, hence did not use the
ConnectionFactory to create local to remote connections.

I'll still add the unit test for port communication. Given that the code was
in this shape, later parts in the code path are untested as well.

Thanks for your patience and lending your coding skills. I hope you win your
lost time back with the things that do work :-)

Peter

> When I read this, I knew you were right but I just couldn't believe it :-]
>
> Thanks for this wonderful work of code review... does it work now?
Actually, no, but I do know why now ;-)

I'm fixing it and will send patches (with explanations) soon.

Sylvain

OK. Here it is. Now, both data and buffer links work. My guts tell me
that read-write connections still do not work though. At least I would
not gamble a lot of money/the life of some student near to the robot on
this ...

I defined a connectPorts on DataFlowInterface so that the connecting
process do not need to get any data flowi object on its side.

One thing though: I don't know one can "adapt" buffered links to data
links and vice-versa (create a data link between a buffer porti and
a data port for instance). If it is the case, the patch 0007 should be
dropped, and the 'connectPorts' call should be split as two different
overloads of connectDataPort and connectBufferPort.

The only thing I'm not sure about is that poping a value from a buffer
link actually trigger something on the producing side (i.e. this is not
a push-pull model). I see that a lot of stuff built around corba event
services is present in the source code, so I assume that it should not
be the case (or maybe it is experimental code, or maybe I don't really
know what corba events are ... :P).

Sylvain

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

me tracking the svn repository with git ;-)

Sylvain

[ This order of contribution should have moved to Orocos-dev :-]

On Monday 17 March 2008 18:06:30 Sylvain Joyeux wrote:
> Follow-up: please commit the patches one by one, that would really help
> me tracking the svn repository with git ;-)

Ok will do.

I had tracked the non-connections to this point in PortInterface::connectTo() :
Index: src/PortInterface.cpp
===================================================================

--- src/PortInterface.cpp       (revision 29069)
+++ src/PortInterface.cpp       (working copy)
@@ -69,18 +69,18 @@

         // if both are not connected, create a new one:
         if ( other->connection() == 0 ) {
-            ConnectionInterface::shared_ptr ci = this->createConnection();
+            ConnectionInterface::shared_ptr ci = this->createConnection(other);
             if (ci) {
-                if ( other->connectTo( ci ) && ci->connect() ) {
+                if ( ci->connect() ) {
                     return true;
                 }
                 // failed, cleanup.
                 this->disconnect();
                 return false;
             }
-            ci = other->createConnection();
+            ci = other->createConnection( this );
             if (ci) {
-                if ( this->connectTo( ci ) && ci->connect() ){
+                if ( ci->connect() ){
                     return true;
                 }
                 // failed, cleanup.

but the buffer (and not data!) connection creation crashed further on. The CorbaPort
did not implement createConnection(void) and did not call the CORBA transport layer.
But I'll merge your patches as soon as I got a look on them.

Peter

On Mon, Mar 17, 2008 at 08:50:55PM +0100, Peter Soetens wrote:
> [ This order of contribution should have moved to Orocos-dev :-]
>
> On Monday 17 March 2008 18:06:30 Sylvain Joyeux wrote:
> > Follow-up: please commit the patches one by one, that would really help
> > me tracking the svn repository with git ;-)
>
> Ok will do.
>
> I had tracked the non-connections to this point in PortInterface::connectTo() :

connectTo is actually not used at all for corba-related connections ...
But this is a good point anyway ;-)

Sylvain

On Tuesday 18 March 2008 10:00:15 Sylvain Joyeux wrote:
> On Mon, Mar 17, 2008 at 08:50:55PM +0100, Peter Soetens wrote:
> > [ This order of contribution should have moved to Orocos-dev :-]
> >
> > On Monday 17 March 2008 18:06:30 Sylvain Joyeux wrote:
> > > Follow-up: please commit the patches one by one, that would really help
> > > me tracking the svn repository with git ;-)
> >
> > Ok will do.
> >
> > I had tracked the non-connections to this point in
> > PortInterface::connectTo() :
>
> connectTo is actually not used at all for corba-related connections ...
> But this is a good point anyway ;-)

It is by TaskContexti::connectPorts(), which is called when you connectPorts()
with two ControlTask objects. Maybe you only tested direct porti-to-port
connection creation using the DataFlowInterface ?

Peter

> > connectTo is actually not used at all for corba-related connections ...
> > But this is a good point anyway ;-)
>
> It is by TaskContexti::connectPorts(), which is called when you connectPorts()
> with two ControlTask objects. Maybe you only tested direct porti-to-port
> connection creation using the DataFlowInterface ?

Actually, yes, now that you mention it ... Since in my case I would only
use that interface, I forgot about the other one ...

However, it seems a bit strange to me that the two code path that are
that much different !

Sylvain

On Monday 17 March 2008 18:02:43 Sylvain Joyeux wrote:
> OK. Here it is. Now, both data and buffer links work. My guts tell me
> that read-write connections still do not work though. At least I would
> not gamble a lot of money/the life of some student near to the robot on
> this ...

You may be right, the intended scenario is this:
when a CorbaPort is involved in the initial creation of a connection (using
the logic of the ConnectionFactory), the local connection is initialised with
a data or buffer CORBA proxy object. This object, when used to read/write the
data, communicates the values over the network. On the remote side, no
ConnectionFactory was used and the new server was created using the
Corba::DataFlowInterface, which serves a data/buffer. On both sides, a
ConnectionInterface object has been created and attached to the porti. One
connection holds a proxy, the other (indirectly) a server. Both connections
only have 1 port attached to them. Hence, when I locally break up the
connection, the remote connection is still alive. This is inconsitent with
the C++ API, which removes all ports when a connection is disconnect()'ed.
For this to work equally, we would need connection management as well in the
CORBA layer. Not a high priority...

>
> I defined a connectPorts on DataFlowInterface so that the connecting
> process do not need to get any data flowi object on its side.

ok.

>
> One thing though: I don't know one can "adapt" buffered links to data
> links and vice-versa (create a data link between a buffer port and
> a data port for instance). If it is the case, the patch 0007 should be
> dropped, and the 'connectPorts' call should be split as two different
> overloads of connectDataPort and connectBufferPort.

This is not possible. Buffered can not be mixed with data. There is a reason
for this: a data object always has a value, while a buffer can be empty or
full. Also, a data object can always be read or written, a buffer can fail to
return or accept a value. This means that the algorithms using one of those
need to know with which kind they communicate. There is one symbiotic state
(which is not present in Orocos): when a buffer is blocking, it behaves like
a data object because a push and pop will always succeed (return true) and
accept or return a value. We could encapsulate that in a DataObjectInterface,
hiding information about the 'buffer state' (full, empty, size, capacity
etc). But this is again not a high priority.

>
> The only thing I'm not sure about is that poping a value from a buffer
> link actually trigger something on the producing side (i.e. this is not
> a push-pull model). I see that a lot of stuff built around corba event
> services is present in the source code, so I assume that it should not
> be the case (or maybe it is experimental code, or maybe I don't really
> know what corba events are ... :P).

I first tried to implement this protocol using the CORBA event service
implemtation in TAO, but it failed to work according to specifications. Not
to say, it failed to work completely at that time. It was easier to define
BufferChannel and use AssignableExpression for this part. It was our
intention to be completely compatible with the ES though.

I've attached the unit test I was working on. I didn't finish it yet, but it
triggered the crash I wrote about earlier.

Peter

On Mon, Mar 17, 2008 at 09:23:07PM +0100, Peter Soetens wrote:
> On Monday 17 March 2008 18:02:43 Sylvain Joyeux wrote:
> > OK. Here it is. Now, both data and buffer links work. My guts tell me
> > that read-write connections still do not work though. At least I would
> > not gamble a lot of money/the life of some student near to the robot on
> > this ...
>
> Not a high priority...
OK. Then the connection stuff should issue either a warning or an error
when someone tries to do this.

> > One thing though: I don't know one can "adapt" buffered links to data
> > links and vice-versa (create a data link between a buffer porti and
> > a data port for instance). If it is the case, the patch 0007 should be
> > dropped, and the 'connectPorts' call should be split as two different
> > overloads of connectDataPort and connectBufferPort.
>
> This is not possible.
Then the checks in the patch are valid.

Sylvain

On Monday 17 March 2008 18:02:43 Sylvain Joyeux wrote:
> OK. Here it is. Now, both data and buffer links work. My guts tell me
> that read-write connections still do not work though. At least I would
> not gamble a lot of money/the life of some student near to the robot on
> this ...

These are my remarks:

1. The corba layer has some wrong usages of the logger:

 log()<< "..."<<endlog(Error); 

It should be

 log(Error)<< "..." <<endlog(); 

The log level must be set always at the beginning. You copy/pasted this
misuse sometimes.

2. Due to the fix in PortInterface::connectTo, it's possible that your createConnection() for readers patch may be dropped. On the other hand,
it could be that the current code always creates a proxy, because the
connection factory is always involved.

3. I like the 'porti mode', it allows more intelligent connection creation.

4. My unit test fails because the connection is created in the wrong direction: ts->connectPorts(ts2) creates the connection data at the side of
ts2, while the C++ code assumes ts creates the connection data object.
An inversion I overlooked in my design. If I loosen the test and don't check
initialisation direction, data ports work, buffer ports as well !
For some reason, the size() returns the wrong number though.

5. when building RTT with your patches, I get
/home/sspr/src/Orocos/trunk/rtt/src/DataPort.hpp: In member function ‘boost::intrusive_ptr<RTT::ConnectionInterface> RTT::ReadDataPort<T>::createConnection(RTT::PortInterface*, RTT::ConnectionTypes::ConnectionType) [with T = double]’:
/home/sspr/src/Orocos/trunk/rtt/src/DataPort.hpp:487: let op: control reaches end of non-void function
/home/sspr/src/Orocos/trunk/rtt/src/BufferPort.hpp: In member function ‘boost::intrusive_ptr<RTT::ConnectionInterface> RTT::ReadBufferPort<T>::createConnection(RTT::PortInterface*, RTT::ConnectionTypes::ConnectionType) [with T = double]’:
/home/sspr/src/Orocos/trunk/rtt/src/BufferPort.hpp:672: let op: control reaches end of non-void function

Probably you forgot a patch ?

All in all, a big improvement. Only the reader's createConnection() I would drop, as it has no initial value,
buffer size etc. set. The PortInterface::connectTo() code contains the code that detects reader-reader
connections and issues the warnings. The problem remains that the connectPorts takes the wrong
direction of data/buffer connection. This needs to be addressed as well, then the reader's createConnection
can be dropped.

Peter

> All in all, a big improvement. Only the reader's createConnection() I would drop, as it has no initial value,
> buffer size etc. set.
As I have written in the patch, it is not a problem since the connection
factory do not use them for local/remote connection establishment. I
don't see how you can drop that, since in loca/remote connection you
will have to create a connection with a local reader to a remote writer.

Mmmm... maybe the local reader/remote writer situation should be taken
care of in CorbaPort::connectPorts ?

Sylvain

On Tuesday 18 March 2008 09:56:53 Sylvain Joyeux wrote:
> > All in all, a big improvement. Only the reader's createConnection() I
> > would drop, as it has no initial value, buffer size etc. set.
>
> As I have written in the patch, it is not a problem since the connection
> factory do not use them for local/remote connection establishment. I
> don't see how you can drop that, since in loca/remote connection you
> will have to create a connection with a local reader to a remote writer.
>
> Mmmm... maybe the local reader/remote writer situation should be taken
> care of in CorbaPort::connectPorts ?

It's all about what is created where. These are the scenarios for a local (L)
to remote (R) connection. I'm not saying that it is implemented like this,
but it is what we should look for. It is the C++ semantics of porti connection.
It is what PortInterface::connectTo implements:

L->connectTo(R);
1. If both ports are not connected:

  1a) if L is a writer:
      * create a local server, instruct the remote port to create a proxy
         which connects to this server.
  1b) if L is a reader:
       1ba) if R is a writer:
            * create a remote server, instruct the local port to create a
               proxy which connects to this server.
        1bb) if R is a reader:
            * create a local default server (very ugly with buffers), instruct
              the remote port to create a proxy which connects to this server

2. If one of both ports is connected:

   2a) if L is connected
   * create a server on the local side, instruct the remote port to create a
      proxy which connects to this server
   2b) if R is connected
   *  create a remote server, instruct the local port to create a proxy which
      connects to this server.

3. if both ports are connected:

   * fail.

The idea is that connections are created from writer to reader, no matter
which one is remote or local, because the writer has the initialisation
and/or buffer capacity. So where the writer is, the server is created and
the reader creates a proxy. Once one of remote/local is connected, it is
easy, always create a proxy to it.

Does this clarify your question ?
Peter

On Tue, Mar 18, 2008 at 09:49:01AM +0100, Peter Soetens wrote:
> 5. when building RTT with your patches, I get
> /home/sspr/src/Orocos/trunk/rtt/src/DataPort.hpp: In member function ‘boost::intrusive_ptr<RTT::ConnectionInterface> RTT::ReadDataPort<T>::createConnection(RTT::PortInterface*, RTT::ConnectionTypes::ConnectionType) [with T = double]’:
> /home/sspr/src/Orocos/trunk/rtt/src/DataPort.hpp:487: let op: control reaches end of non-void function
> /home/sspr/src/Orocos/trunk/rtt/src/BufferPort.hpp: In member function ‘boost::intrusive_ptr<RTT::ConnectionInterface> RTT::ReadBufferPort<T>::createConnection(RTT::PortInterface*, RTT::ConnectionTypes::ConnectionType) [with T = double]’:
> /home/sspr/src/Orocos/trunk/rtt/src/BufferPort.hpp:672: let op: control reaches end of non-void function
>
> Probably you forgot a patch ?
Mmmm ... No (was there a hole in the numbering on your side ?).

Sylvain

On Tuesday 18 March 2008 10:03:07 Sylvain Joyeux wrote:
> On Tue, Mar 18, 2008 at 09:49:01AM +0100, Peter Soetens wrote:
> > 5. when building RTT with your patches, I get
> > /home/sspr/src/Orocos/trunk/rtt/src/DataPort.hpp: In member function
> > ‘boost::intrusive_ptr<RTT::ConnectionInterface>
> > RTT::ReadDataPort<T>::createConnection(RTT::PortInterface*,
> > RTT::ConnectionTypes::ConnectionType) [with T = double]’:
> > /home/sspr/src/Orocos/trunk/rtt/src/DataPort.hpp:487: let op: control
> > reaches end of non-void function
> > /home/sspr/src/Orocos/trunk/rtt/src/BufferPort.hpp: In member function
> > ‘boost::intrusive_ptr<RTT::ConnectionInterface>
> > RTT::ReadBufferPort<T>::createConnection(RTT::PortInterface*,
> > RTT::ConnectionTypes::ConnectionType) [with T = double]’:
> > /home/sspr/src/Orocos/trunk/rtt/src/BufferPort.hpp:672: let op: control
> > reaches end of non-void function
> >
> > Probably you forgot a patch ?
>
> Mmmm ... No (was there a hole in the numbering on your side ?).

$ ls 00*patch -1
0002-corba-fix-crash-when-the-connection-creation-fails.patch
0003-corba-cleaning.patch
0004-corba-define-connectPorts-on-DataFlowInterface.patch
0005-corba-implement-createConnection-on-reader-ports.patch
0006-corba-remove-leftovers-from-previous-merges.patch
0007-corba-validate-porti-types-when-making-connections.patch
0008-corba-fix-a-bad-void-cast.patch
0009-corba-trivial-fix-for-BufferChannel-empty.patch
0010-corba-DataFlowInterface-connectPorts-does-not-nee.patch

$ for i in 00*patch ; do patch -p1 < $i; done
patching file src/corba/DataFlowI.cpp
patching file src/corba/DataFlowI.cpp
patching file src/corba/DataFlow.idl
patching file src/corba/DataFlowI.cpp
patching file src/corba/DataFlowI.h
patching file src/BufferPort.hpp
patching file src/DataPort.hpp
patching file src/corba/DataFlowI.cpp
patching file src/BufferPort.hpp
patching file src/DataPort.hpp
patching file src/PortInterface.hpp
patching file src/corba/CorbaPort.hpp
patching file src/corba/DataFlow.idl
patching file src/corba/DataFlowI.cpp
patching file src/corba/DataFlowI.h
patching file src/corba/CorbaTemplateProtocol.hpp
patching file src/corba/DataFlowI.h
patching file src/corba/DataFlow.idl
patching file src/corba/DataFlowI.cpp
patching file src/corba/DataFlowI.h

$ cat -n src/DataPort.hpp |head -490 | tail -20

   471      }
   472
   473      template<class T>
   474      ConnectionInterface::shared_ptr 

ReadDataPort<T>::createConnection(PortInterface* other,
ConnectionTypes::ConnectionType con_type)

   475      {
   476          // If the other side is remote, we must create the connection
   477          // ourselves. In that case, the initial value and buffer size 

are not

   478          // used by the connection factory.
   479          //
   480          // This is a hack -- it needs a proper solution.
   481          if (other->serverProtocol())
   482          {
   483              ConnectionFactory<T> cf;
   484              return ConnectionInterface::shared_ptr ( 

cf.createDataObject(other, this, T(), con_type) );

   485          }
   486          else
   487              other->createConnection(this, con_type);
   488      }

Does not have a return statement...

Peter

[ now really moving this to Orocos-dev]

On Monday 17 March 2008 18:02:43 Sylvain Joyeux wrote:
> OK. Here it is. Now, both data and buffer links work. My guts tell me
> that read-write connections still do not work though. At least I would
> not gamble a lot of money/the life of some student near to the robot on
> this ...

Other remarks about the patches:

• please use spaces as indentation, with a width of 4.
• The following function still has issues:

    template<class T>
    ConnectionInterface::shared_ptr 

ReadDataPort<T>::createConnection(PortInterface* other,
ConnectionTypes::ConnectionType con_type)

    {
    // If the other side is remote, we must create the connection
    // ourselves. In that case, the initial value and buffer size are not
    // used by the connection factory.
    //
    // This is a hack -- it needs a proper solution.
    if (other->serverProtocol())
    {
        ConnectionFactory<T> cf;
        return ConnectionInterface::shared_ptr ( cf.createDataObject(other, 

this, T(), con_type) );

    }
    else
        other->createConnection(this, con_type);
    }

Apart from the missing return statement, it will cause endless recursion when
two read ports are connected. I understand now that otherwise, it works:
other is a remote write porti and will create the buffer correctly, while we
get a proxy in return. ok.

Nevertheless, PortInterface::connectTo() has this logic as well. It will first
ask the read port to create a connection.That will fail (in my
implementation) and then it will ask the write port to create a connection,
which will do like you want, resulting in the same behaviour. Maybe we can
adapt your DataFlowI.cpp code such that it uses PortInterface::connectTo(),
and then the code snippet above can go away.

BTW, do you mind if I commit your patches one by one, but set the indentation
right, or do you prefer to resubmit ?

Peter

On Tue, Mar 18, 2008 at 04:40:23PM +0100, Peter Soetens wrote:
> BTW, do you mind if I commit your patches one by one, but set the indentation
> right, or do you prefer to resubmit ?
Please commit, that would be better.

As far as I understand, connectPorts should never be used directly, but
connectTo should always be used instead ... So it is better that
DataFlowInterface implementation uses it as well.

Sylvain

On Monday 17 March 2008 11:03:12 Sylvain Joyeux wrote:
> OK. RTT does not end in the code path it is supposed to. I end up having
> a warning at ConnectionFactory.hpp:186 while it should have went into
> the conn_buffer != NULL case ... Strange.

You can get in there if no suitable CORBA transport was found (tt==0).
The CORBA transport layer should have logged an error/warning though
before that happens.

Peter