Re: Updated dataflow semantics for RTT

--===============0519988887==
Content-Type: multipart/alternative; boundary=089e013c6e9aa1d3510520476284

--089e013c6e9aa1d3510520476284
Content-Type: text/plain; charset=UTF-8

Hi Sylvain,

thanks for your quick reply!

On Mon, Sep 21, 2015 at 8:09 PM, Sylvain Joyeux <[email protected]>
wrote:

> Quick comment -- I don't have a lot of time on my hands right now:
>
> To me, it looks like you have decided that push is shared by default,
> in your description the concept of pull/push and private/shared. Am I
> wrong ? Is "push/shared" different than "push with single buffer by
> default" ? I would not see the rationale for that, if a use wants
> "private", give him "private", especially given that there are
> shortcomings ...
>
> Using "shared" will make the system fail if, later, it gets a
> connection request for a different policy than the original policy. To
> me, this spells that using shared MUST be a conscious choice of the
> system designer in all cases OR that there should be a way for RTT to
> degrade gracefully from shared to private (use shared as an
> optimization that is handled purely internally unless the user
> requested it explicitely).
>
> In general, the connection code will have to return an error if trying
> incompatible mixes of policies.
>
> Sylvain
>


That's exactly what he have in mind and how it is hopefully implemented.
push/pull and private/shared are orthogonal concepts. The default would be
push/private. Connections are never shared unless explicitly specified by
the user. Probably the table in section 5.1 of our design document
<https://docs.google.com/document/d/1zDnPPz4SiCVvfEFxYFUZBcVbXKj33o4KaotpCtXM4E0/pub#h.yfd89u4uuk9u>
is
the easiest mean to get a fast overview of the possible combinations.

These are the shortest possible definitions I can come up with:

push: Every input port has a single input buffer and all connected writers
write into that buffer.
pull: Every output port has one buffer per connection and readers will poll
all connected writers for new data.

private: Every connection buffer belongs to exactly one input port, so all
read operations are independent from each other.
shared: Multiple input ports can read from the same buffer, so one read
operation can influence the outcome of another.

The combination shared/pull is less intuitive, but we interpreted it as a
single local output buffer and multiple polling input ports read from the
same buffer (vs. one buffer per connection in the pull/private case).
Actually this connection type would only be useful for shared remote
connections, where multiple remote input ports are supposed to consume
samples from a single output port with a shared local buffer. For local
connections, there is no reason not to use a shared/push connection.

Clearly there are limitations for the possible combinations of different
connection types for a single port, primarily that an input port can have
either only pull or only push connections and that all push connections
have to be consistent in the buffer type, size and locking policy. For
illegal combinations the connectTo(...) request (or whatever API is used to
establish new connections) will return an error. Users have to be more
careful and aware of the implications of ConnPolicy flags, but we think the
default private/push should work for most applications and not break
existing deployments, unless they already use a mixture of connection
policies for the same port for whatever reason.

Johannes


-- 
Johannes Meyer, Senior Application Engineer
+32 468 139828
Intermodalics - Kapeldreef 60, 3001 Heverlee - BELGIUM
www.intermodalics.eu

--089e013c6e9aa1d3510520476284
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Sylvain,<div><br></div><div>thanks for your quick reply=
!<br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Sep =
21, 2015 at 8:09 PM, Sylvain Joyeux <span dir=3D"ltr">&lt;<a href=3D"mailto=
:[email protected]" target=3D"_blank">[email protected]</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">Quick comment -- I don&#39;t=
 have a lot of time on my hands right now:<br>
<br>
To me, it looks like you have decided that push is shared by default,<br>
in your description the concept of pull/push and private/shared. Am I<br>
wrong ? Is &quot;push/shared&quot; different than &quot;push with single bu=
ffer by<br>
default&quot; ? I would not see the rationale for that, if a use wants<br>
&quot;private&quot;, give him &quot;private&quot;, especially given that th=
ere are<br>
shortcomings ...<br>
<br>
Using &quot;shared&quot; will make the system fail if, later, it gets a<br>
connection request for a different policy than the original policy. To<br>
me, this spells that using shared MUST be a conscious choice of the<br>
system designer in all cases OR that there should be a way for RTT to<br>
degrade gracefully from shared to private (use shared as an<br>
optimization that is handled purely internally unless the user<br>
requested it explicitely).<br>
<br>
In general, the connection code will have to return an error if trying<br>
incompatible mixes of policies.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Sylvain<br>
</font></span></blockquote></div><br><br></div><div class=3D"gmail_extra">T=
hat&#39;s exactly what he have in mind and how it is hopefully implemented.=
 push/pull and private/shared are orthogonal concepts. The default would be=
 push/private. Connections are never shared unless explicitly specified by =
the user. Probably the table in <a href=3D"https://docs.google.com/document=
/d/1zDnPPz4SiCVvfEFxYFUZBcVbXKj33o4KaotpCtXM4E0/pub#h.yfd89u4uuk9u">section=
 5.1 of our design document</a>=C2=A0is the easiest mean to get a fast over=
view of the possible combinations.</div><div class=3D"gmail_extra"><br></di=
v><div class=3D"gmail_extra">These are the shortest possible definitions I =
can come up with:</div><div class=3D"gmail_extra"><br></div><div class=3D"g=
mail_extra">push: Every input port has a single input buffer and all connec=
ted writers write into that buffer.</div><div class=3D"gmail_extra">pull: E=
very output port has one buffer per connection and readers will poll all co=
nnected writers for new data.</div><div class=3D"gmail_extra"><br></div><di=
v class=3D"gmail_extra">private: Every connection buffer belongs to exactly=
 one input port, so all read operations are independent from each other.</d=
iv><div class=3D"gmail_extra">shared: Multiple input ports can read from th=
e same buffer, so one read operation can influence the outcome of another.<=
/div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">The co=
mbination shared/pull is less intuitive, but we interpreted it as a single =
local output buffer and multiple polling input ports read from the same buf=
fer (vs. one buffer per connection in the pull/private case). Actually this=
 connection type would only be useful for shared remote connections, where =
multiple remote input ports are supposed to consume samples from a single o=
utput port with a shared local buffer. For local connections, there is no r=
eason not to use a shared/push connection.</div><div class=3D"gmail_extra">=
<br></div><div class=3D"gmail_extra">Clearly there are limitations for the =
possible combinations of different connection types for a single port, prim=
arily that an input port can have either only pull or only push connections=
 and that all push connections have to be consistent in the buffer type, si=
ze and locking policy. For illegal combinations the connectTo(...) request =
(or whatever API is used to establish new connections) will return an error=
. Users have to be more careful and aware of the implications of ConnPolicy=
 flags, but we think the default private/push should work for most applicat=
ions and not break existing deployments, unless they already use a mixture =
of connection policies for the same port for whatever reason.</div><div cla=
ss=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Johannes</div><div =
class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><div><br></div>-=
- <br><div class=3D"gmail_signature"><div dir=3D"ltr"><span style=3D"color:=
rgb(136,136,136)">Johannes Meyer, Senior Application Engineer</span><br><sp=
an><font color=3D"#888888">+32=C2=A0</font></span>468 139828<span><font col=
or=3D"#888888"><br>
Intermodalics - Kapeldreef 60, 3001 Heverlee - BELGIUM<br>
<a href=3D"http://www.intermodalics.eu" target=3D"_blank">www.intermodalics=
.eu</a></font></span></div></div>
</div></div></div>

--089e013c6e9aa1d3510520476284--

--===============0519988887==
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

--===============0519988887==--