[prev in list] [next in list] [prev in thread] [next in thread] 

List:       orocos-dev
Subject:    [Orocos-Dev] Replacing events in RTT 2.0 & script state machines
From:       peter.soetens () gmail ! com (Peter Soetens)
Date:       2010-02-04 15:52:54
Message-ID: 201002041652.54553.peter.soetens () gmail ! com
[Download RAW message or body]

On Monday 25 January 2010 17:09:24 Klaas Gadeyne wrote:
> On Thu, Jan 21, 2010 at 4:24 PM, Peter Soetens <peter.soetens at gmail.com> 
wrote:
> > One of the more drastic things to change in RTT 2.0 is that RTT::Events
> > as they were will no longer exist. Their drawback were that events could
> > get lost, (it had a fifo buffer of only size one) and especially, it
> > could trash the event emitter if 'hostile' callbacks were attached
> > synchronously.
> >
> > We (at least some of us) agreed to replace them by dataflow ports. You
> > can specify a buffering policy, they are thread-safe and real-time,
> > distributed and the callback is handling is simple and efficient and they
> > can wake up task contexts.
> >
> > Ports solve event delivery across components, but one convenience of the
> > old event implementation was that our script state machines could react
> > to them. The question is how to do this in 2.0.
> >
> > Clearly, we'll need a way to react to data delivery on ports on one hand
> > (events generated by peer components) but also allow the algorithms
> > *inside* the component to emit an event which is handled by its own state
> > machines (local delivery). If you used this before, you know what I mean.
> 
> I know what you did last summer? :-)
> 
> Seriously, if I read the above, I get the impression that your only
> concern for 2.0 is to offer the user the same capabilities as he had
> with 1.x.

I'll come back to that later.

> For me (and others around here), statemachines in 1.x are a PITA.
> When I have to explain FSMs to somebody, I always get "red cheeks".

I don't. I even make a living out of it :-)

> <quote>
> You had a method in the interface of your component, but now you want
> also to react on that "methodevent" in your FSM?  Ha, you'll have to
> create an event now and add that to the components API.
> <quote>

What you're aiming at is a UML-like protocol state machine, where transitions
define the valid operations of the component ? Can you propose script syntax + 
semantics ? Take into account that the operation may(?) be called multiple 
times before the SM had a chance to run.

We can add operations to the interface of a component by writing down 
functions in program scripts already, but I can see that's not what you're 
talking about.

> 
> [I guess I advocated this already before :-)]
> Basically I would like to see the (internal) event used in the
> statemachine _decoupled_ from the "thing" that triggers the event!
> 
> > Proposed solution:
> > 1) Create a 'LoopBackPort' next to InputPort and OutputPort. It is a data
> > flow port that reads what you wrote into it. you can connect it to itself
> > and as such set a buffering policy etc. The scripting state machine react
> > to data on this port, like they react to data from InputPorts. I'm a bit
> > uneasy about the 'LoopBackPort' name though.
> 
> I think you need to set this "uneasy" step exactly because of the fact
> that you don't distinguish between the above 2 concepts...

Lets forget that 'solution' completely. But my humble solutions don't deny the 
fact that 'reacting asynchronously to an event' needs a buffering policy.

> 
> > 2) Change the event transition syntax from:
> 
> [...]
> 
> > The only thing the user then has to add is using addEventPort() for
> > registering the InputPort or LoopBackPort to the dataflow interface.
> > These will trigger the TaskContext when data arrives, which will execute
> > the script, which will read the port and get NewData.
> >
> > The major difference between old and new a user will feel is that old
> > events allowed multipe arguments (ie event_name(a,b,c)) while ports only
> > allow one argument (ie port_name(a) ). This means you need to rewrite
> > multiple arguments into a C struct and register it with the type system.
> > This shouldn't be a big issue once typekits can be generated on the fly
> > (we're working on this, remember), but for large applications that rely
> > on this, it's a painful change.
> >
> > Thoughts ?
> 
> I don't know wether migration from 1.x legacy should be the primary
>  concern.

It _is_, with respect to the scripting syntax. It's not my aim to invent a 
new, better scripting language. I'm bad at it anyway, or at least, I was so in 
the past. The major objective is to keep the 1.x scripting syntax in 2.x with 
the minimal ammount of changes, such that existing users can at least reason 
about the cost of transitioning to 2.x. If you want to write a script from 
scratch, I recommend to use Lua, which Markus will offer us for endless joy in 
our lives.

Peter

[prev in list] [next in list] [prev in thread] [next in thread]