On Tuesday 03 November 2009 15:21:48 you wrote:
> On Tue, Nov 3, 2009 at 12:45, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
> > What I call here a data-driven task is a task that does its computation
> > whenever new data is available on one of its input ports. This is
> > currently set up through the DataFlowInterface::addEventPort method and
> > the use of a non-periodic activity (NonPeriodicActivity of old, Activity
> > with a zero period in RTT2)
> >
> > Now, my problem: updateHook() gets called at startup.
> >
> > I don't have time to track it down, but my guess is that start() calls
> > the activity's loop(), which in turn calls step() once and therefore
> > updateHook().
>
> Correct. Just like start() on a periodic activity will cause step() to
> be executed, start() on a non periodic activity causes a call to
> loop(). If you don't want this, but still like to react to events,
> call activate() instead. An active component does not execute its
> updateHook(), but does process event callbacks and commands.
The two cases are different. The first call to step() on a periodic activity is
actually meaningful because this first event is part of the actual triggers
(first trigger of the periodic event set). The first call of step() by the other
activities is *not* part of the triggering events (data flow).

In other words, by calling TaskContext#start, one is only asking the STOPPED-
>RUNNING transition, not the RUNNING->RUNNING transition. It so happens that,
in the case of the periodic activities, it has a sense that one RUNNING-
>RUNNING transition happens as soon as we enter RUNNING.

IMO, the problem is that the loop()/trigger() mechanism is not used by
default, but is instead replaced "under the hood" by repeated calls to start()
[or explicit calls to step()]. This is completely absurd as, in effect, we have
running task contexts that run on a not-really-running activity. Moreover,
activities have to do some magic: how come repeated calls to start() do not
call initialize() ?

> > It seems wrong to me, since start() means "prepare yourself to be
> > triggered", and not "be triggered here". The problem is that the fix
> > would require removing the call to step() in the default
> > Activity::loop(). In itself, I don't see it as a problem but I guess that
> > others might have an use for it.
> >
> > What's your point of view ?
>
> updateHook() is controversial. Some people call it a hack only
> necessary for periodic execution (which is in turn a considered as a
> hack), some even proposed to remove it. The difference
> activated/running proves this too in a way. I find it acceptable as it
> is, but I can imagine smarter people can think of a simpler and
> cleaner solution. I'm all ears.
Well ... I was actually going into the side of removing the "activated" state
but keeping updateHook(). updateHook() is not necessary "only for periodic
execution", but for anything that needs to trigger the running-to-running
state transition repeatedly: data triggers, I/O triggers, periodic triggers.
That's about all the components I have running there.

Given that commands and methods do not provide a complete error reporting and
error handling structure, they are IMO unsuited for the bulk of the module
implementation -- but are good to interact with a running task context (i.e. a
repeatedly called updateHook()).