Re: Updated dataflow semantics for RTT

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-986400326-1443445027=:30972
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

On Mon, 28 Sep 2015, S Roderick wrote:

>
> On Sep 28, 2015, at 08:44 AM, Herman Bruyninckx=20
> <[email protected]> wrote:
>
> On Mon, 28 Sep 2015, S Roderick wrote:
>
> On Sep 27, 2015, at 08:11 AM, Herman Bruyninckx
> <[email protected]> wrote:
>
> On Mon, 21 Sep 2015, Johannes Meyer wrote:
>
> Dear Orocos community,
> during the last few weeks we have been working on the concept and
> implementation of a major redesign of the Orocos
> RTT dataflow, that we would like to share and ask for your valuable fee=
dback.
> There was already a previous
> discussion on the mailing list about the topic earlier this year [1], a=
nd the
> following proposal tries to address
> all the issues mentioned there.
>
> With the version 2 of the Orocos toolchain some years ago, the previous=
 data
> flow architecture, which was based on a
> single data object and buffer shared between all ports participating at=
 the
> same connection, was replaced by a
> connection architecture based on data flow, where each pair of output a=
nd
> input ports (or streams) is connected
> through an individual channel, each having its own data object or buffe=
r.
> While there was a well substantiated
> motivation for this update and it solved some of the shortcomings in RT=
T
> version 1 [2], it also introduced some new,
> sometimes hidden, problems and broke other use cases. One example is an=
 input
> port with multiple connections, where
> due to the ambiguity in which channel to read from the result is someti=
mes
> unexpected to the user, who expects that
> each write overwrites previous samples in case of simple data connectio=
ns.
>
> We assembled a document (see attachment, or [3]) which introduces the v=
ersion
> 1 and version 2 data flow semantics
> for those who are not aware of the details, three example use cases and
> presents the new dataflow architecture we
> have in mind, which ideally works for a superset of use cases that are
> supported by RTT version 1 and 2.=C2=A0
>
> We do not want to go into details here, so only a short summary for tho=
se who
> do not want to read the full document:
> We propose to add two more boolean flags to the ConnPolicy struct that
> describes the type of connection between two
> ports: "shared" and "mandatory". Furthermore the existing "pull" flag, =
which
> was only meaningful for remote
> connections, now has a big influence for local connections.
>
> "push" vs. "pull"
>
>
> Thanks for this nice effort. I think it is really time to consider a ne=
xt
> generation of Orocos RTT...
>
> If you allow me to bring in my two cents... It's possible that you won'=
t like
> the
> message, or find it off-topic, but I think I should share it with you a=
nyway=E2=80=A6
>
> These are interesting ideas Herman, but=C2=A0you're right in that they'=
re somewhat
> off topic. For this discussion we are interested in the here and now - =
in
> evolutionary and incremental changes to a product=C2=A0that has served =
many of us
> fairly well.
>
> The evolution from the current "data flow architecture" to a "event str=
eam"
> _can_/_could_ be done in an incremental way...
> Policy by policy. (i.e., pull/push; read/write; buffer/port;...)=20
> Separation by separation. (i.e., component/activity/thread/OS; pub/sub =
to
> event stream;...)
> =C2=A0
> With all due respect, I think that your idea of "incremental" and mine =
are=20
> two very different things (and both are equally valid). It took us two =
full=20
> years to convert our system from RTT v1 to RTT v2. There is no way we w=
ould=20
> even consider moving to a RTT replacement without some serious review a=
nd up=20
> front discover and prototype use of a replacement system. So incrementa=
l for=20
> us is defined in months to years =E2=80=A6

Again I agree. But I see no reason why introducing less strict policies c=
an
not be done alongside keeping the existing ones...
Of course, it would result in a transition phase with even more conceptua=
l
complexity than what is there now already, but it would allow the kind of
comparative prototyping you have in mind.

My concrete suggestion for such incremental "revolution": add a "event
stream" to complement the "lock-free buffer", as a second realtime-ready
internal IPC. This development is worth the effort anyway, and I know of =
no
implementation that is realtime ready... (Building further on TLSF and
MQueue might be low hanging fruit. Might be...)
This boils down to _adding_ a feature, which is always simpler than
deprecating one. And _if_ it turns out that it can cover the use cases of
the lockfree buffer (and some others) equally well, one could deprecate
those, later one.

> Personally, I'm not so worried about "better" as I am worried
> about "good enough".
>
> I am mostly interested in "simple". Because that is what determines how
> much of the potential mind share a project actually gets.
> (Mind that I am not interested in "easy", which is the driver for ROS, =
and
> that serves another public well.)
> =C2=A0
> +1 on simple.
> S
>
>
--8323329-986400326-1443445027=:30972
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--8323329-986400326-1443445027=:30972--