Re: Updated dataflow semantics for RTT
Willy Lambert <[email protected]> Tue, 22 Sep 2015 13:26:45 +0200
| Newsgroups | gmane.science.robotics.orocos.devel |
|---|---|
| Message-ID | <CAKvQZ_2qkqAX5v9WJiMRXLv6CBL8Mjbh0uxYLyjbWihOsnbcRw@mail.gmail.com> |
--===============1677631655== Content-Type: multipart/alternative; boundary=089e01182fe8e37a3a052054459e --089e01182fe8e37a3a052054459e Content-Type: text/plain; charset=UTF-8 2015-09-21 22:03 GMT+02:00 Johannes Meyer <[email protected]>: > 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 > > -- > Orocos-Dev mailing list > [email protected] > http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev > > Do you know about RabbitMq ? It may be a source of inspiration, or if doing the job, a good externalisation. https://www.rabbitmq.com/getstarted.html --089e01182fe8e37a3a052054459e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">= 2015-09-21 22:03 GMT+02:00 Johannes Meyer <span dir=3D"ltr"><<a href=3D"= mailto:[email protected]" target=3D"_blank">johannes@intermodalics.= eu</a>></span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px= 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><di= v dir=3D"ltr">Hi Sylvain,<div><br></div><div>thanks for your quick reply!<b= r><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"><<a href=3D"mailto:sy= [email protected]" target=3D"_blank">[email protected]</a>></spa= n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px = 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Quick commen= t -- I don'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 "push/shared" different than "push with single bu= ffer by<br> default" ? I would not see the rationale for that, if a use wants<br> "private", give him "private", especially given that th= ere are<br> shortcomings ...<br> <br> Using "shared" 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><font color=3D"#888888"><br> Sylvain<br> </font></span></blockquote></div><br><br></div><div class=3D"gmail_extra">T= hat'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" target= =3D"_blank">section 5.1 of our design document</a>=C2=A0is the easiest mean= to get a fast overview of the possible combinations.</div><div class=3D"gm= ail_extra"><br></div><div class=3D"gmail_extra">These are the shortest poss= ible definitions I can come up with:</div><div class=3D"gmail_extra"><br></= div><div class=3D"gmail_extra">push: Every input port has a single input bu= ffer and all connected writers write into that buffer.</div><div class=3D"g= mail_extra">pull: Every output port has one buffer per connection and reade= rs will poll all connected writers for new data.</div><div class=3D"gmail_e= xtra"><br></div><div class=3D"gmail_extra">private: Every connection buffer= belongs to exactly one input port, so all read operations are independent = from each other.</div><div class=3D"gmail_extra">shared: Multiple input por= ts can read from the same buffer, so one read operation can influence the o= utcome of another.</div><div class=3D"gmail_extra"><br></div><div class=3D"= gmail_extra">The combination shared/pull is less intuitive, but we interpre= ted it as a single local output buffer and multiple polling input ports rea= d from the same buffer (vs. one buffer per connection in the pull/private c= ase). Actually this connection type would only be useful for shared remote = connections, where multiple remote input ports are supposed to consume samp= les from a single output port with a shared local buffer. For local connect= ions, there is no reason not to use a shared/push connection.</div><div cla= ss=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Clearly there are l= imitations for the possible combinations of different connection types for = a single port, primarily that an input port can have either only pull or on= ly push connections and that all push connections have to be consistent in = the buffer type, size and locking policy. For illegal combinations the conn= ectTo(...) request (or whatever API is used to establish new connections) w= ill return an error. Users have to be more careful and aware of the implica= tions of ConnPolicy flags, but we think the default private/push should wor= k for most applications and not break existing deployments, unless they alr= eady use a mixture of connection policies for the same port for whatever re= ason.</div><span class=3D""><font color=3D"#888888"><div class=3D"gmail_ext= ra"><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><div= dir=3D"ltr"><span style=3D"color:rgb(136,136,136)">Johannes Meyer, Senior = Application Engineer</span><br><span><font color=3D"#888888">+32=C2=A0</fon= t></span>468 139828<span><font color=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></font></span></div></div> <br>--<br> Orocos-Dev mailing list<br> <a href=3D"mailto:[email protected]">[email protected].= kuleuven.be</a><br> <a href=3D"http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev" rel= =3D"noreferrer" target=3D"_blank">http://lists.mech.kuleuven.be/mailman/lis= tinfo/orocos-dev</a><br> <br></blockquote></div><br>Do you know about RabbitMq ?=C2=A0 It may be a s= ource of inspiration, or if doing the job, a good externalisation.<br><a hr= ef=3D"https://www.rabbitmq.com/getstarted.html">https://www.rabbitmq.com/ge= tstarted.html</a><br><br></div></div> --089e01182fe8e37a3a052054459e-- --===============1677631655== 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 --===============1677631655==--