On Wednesday June 4 2008 11:26:22 Klaas Gadeyne wrote:
> On Wed, 4 Jun 2008, Ruben Smits wrote:
> > On Wednesday June 4 2008 10:42:44 Klaas Gadeyne wrote:
> >> On Wed, 4 Jun 2008, Ruben Smits wrote:
> >>>>> since i use an empty TaskContext all the time to execute my
> >>>>> statemachine and program scripts i thought adding a deployable one to
> >>>>> liborocos-ocl-common would not be a bad idea.
> >>>>>
> >>>>> patch in attachment, if no-one complains i'll commit.
> >>>>
> >>>> FWIW, I recently used the deployment component itself for similar
> >>>> purposes.
> >>>
> >>> Adding a realtime activity for script execution to the highly non
> >>> realtime deployment component does not bring you into trouble? What
> >>> happens if you start loading a new component during the execution of a
> >>> statemachine?
> >>
> >> IMO The deployment component is not different from _any other_ component
> >> in that sense: 1/ it is not connected to an activity by default, so you
> >> can connect it to an activity scheduled as ORO_SCHED_RT. 2/ As with any
> >> other component, you have to make sure that you know what you're doing.
> >> Loading your libraries, creating your peer network, etc. are implemented
> >> as orocos Methods and hence typically executed in the thread of the
> >> *caller*. Hence I don't understand what you mean by highly non realtime?
> >>
> >> This said:
> >> - Lazy as I am, I was just using it to avoid having to type too much,
> >> and was not interested in the real-time execution of my script - My
> >> script was also "deployment functionality" oriented, hence in that sense
> >> it was "logical" to execute it in the deployment component.
> >>
> >> However, the last statement brings up another issue I guess: what
> >> "functionality" is executed in your scripts? Shouldn't the answer to
> >> that question tell you in which component the script should be executed?
> >
> > Indeed, in our application (containing more than 20 components including
> > some remote ones) i should have a realtime supervising component that
> > executes scripts, which brought me to the empty taskcontext :)
>
> Does those scripts involve starting/stopping some of those components?

Yes,

> Because I think this then requires that your startHook() and stopHook()
> functions don't contain non-realtime code?

Offcourse, all non-realtime code is moved to the configureHook(),
cleanupHook(), which are executed by the deployment component.

Ruben

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

On Wed, 4 Jun 2008, Klaas Gadeyne wrote:

[...]

_very_ interesting remarks you make here below, Klaas!

> Note (@Stephen et al): Next to Herman's remarks on the orocos *FSM* alignment
> with UML [*], the above is an (*one*) issue I would like to see sorted in
> orocos 2.0. UML provides "operations", and it's the fact whether a class is
> active or not that decides if that operation is executed synchronously (in
> the thread of the caller) or asynchronously (in *a* thread of the active
> class).
>
> In orocos, things are organised differently:
> - The TaskContext class is decoupled completely from a thread. However, how
> can you *design* a class if you don't know how it will be used?
> - You have the choice to implement functionality as either a method or a
> command, even if you don't know
> *who will call that method/command
> *if the method will be called in a real-time thread.
>
> This results in what I consider flaws of the current orocos "execution
> model": [**]
> 1/ Calling a Method of a peer TaskContext can result in non-realtime
> behaviour of the (real-time) caller
> 2/ A TaskContext can be designed to be executed real-time periodically, but
> in the application connected to a non-realtime non-periodic activity
>
> I wonder if things wouldn't be simplified if orocos TaskContexts are
> "coupled" (yes coupled) to Activities, and if Methods/Commands were replaced
> by "Operations". Whether those Operations are executed in the thread of the
> caller or not, is decided based on the fact whether that activity is
> (Non)Periodic vs Slave. This would mean that, f.i. functions as startHook()
> etc. are executed in the thread of the caller in case the TC is connected to
> a SlaveActivity, and in the thread of the TC in the other case. An added
> benefit I see is that this would simplify the API of the taskContext.
>

> ps. This is just food for thoughts, I hope it's not *too* unclear and I'm
> sure I'm still missing lots of stuff here.

Markus should follow this up in the following months, and design the refactoring...

Herman

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm