[Bug 562] New: Deployable empty TaskContext

For more infomation about this bug, visit
Summary: Deployable empty TaskContext
Product: OCL
Version: trunk
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Other
AssignedTo: orocos-dev [..] ...
ReportedBy: ruben [dot] smits [..] ...
CC: orocos-dev [..] ...
Estimated Hours: 0.0

Created an attachment (id=314)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=314)
deployable empty taskcontext

Hi,

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.

Ruben

[Bug 562] Deployable empty TaskContext

For more infomation about this bug, visit

Peter Soetens
<peter [dot] soetens [..] ...> changed:

What |Removed |Added
--------------------------------------------------------------------------
CC| |peter [dot] soetens [..] ...

--- Comment #2 from Peter Soetens
<peter [dot] soetens [..] ...> 2008-06-04 13:31:09 ---
(In reply to comment #0)
> Created an attachment (id=314)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=314) [details]
> deployable empty taskcontext
>
> Hi,
>
> 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.

Is fine for me, even just for testing/debugging purposes. However, with respect
to your execution problem, you can

setPeriodicActivity("Deployer", 0.001, 0, 0)

and then load'n run your scripts in the deployer.

Having the same in the XML syntax is on my todo list and hopefully a minor
effort.



...

Peter

[Bug 562] Deployable empty TaskContext

For more infomation about this bug, visit

--- Comment #1 from Klaas Gadeyne <klaas [dot] gadeyne [..] ...> 2008-06-04 10:00:13 ---
Hi Ruben,

(In reply to comment #0)
> 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.

Ruben Smits's picture

[Bug 562] Deployable empty TaskContext

On Wednesday June 4 2008 10:00:13 Klaas Gadeyne wrote:
> For more infomation about this bug, visit
>
>
>
>
> --- Comment #1 from Klaas Gadeyne <klaas [dot] gadeyne [..] ...> 2008-06-04
> 10:00:13 --- Hi Ruben,
>
> (In reply to comment #0)
>
> > 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?

Ruben

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

[Bug 562] Deployable empty TaskContext

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?

Klaas

Ruben Smits's picture

[Bug 562] Deployable empty TaskContext

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 :)

Ruben

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

[Bug 562] Deployable empty TaskContext

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

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.

regards,

Klaas

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.

[*] I should *really* find some time to align my thoughts on orocos "2.0" and answer in that thread :-(
[**] One *could* argue this is the responsibility of the application designer to get these things straight.

Ruben Smits's picture

[Bug 562] Deployable empty TaskContext

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

[Bug 562] Deployable empty TaskContext

On Wed, 4 Jun 2008, Ruben Smits wrote:
[..]
>> 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.

[to confirm my reputation as a nitpicker :-)]

Strictly speaking I would say they are *not* "executed by the deployment component", since the latter is (by default) not associated with an activity. So I guess in your code the non-realtime code is executed in the MainThread, which is perfectly fine. But which also leave the possiblity open to execute your real-time script in the EE of the deployment component, associated with a RT activity (hence confirming its role as "supervisor").

Klaas

[Bug 562] Deployable empty TaskContext

On Wed, Jun 4, 2008 at 11:50 AM, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
> On Wed, 4 Jun 2008, Ruben Smits wrote:
> [..]
>>>
>>> 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.
>
> [to confirm my reputation as a nitpicker :-)]
>
> Strictly speaking I would say they are *not* "executed by the deployment
> component", since the latter is (by default) not associated with an
> activity. So I guess in your code the non-realtime code is executed in the
> MainThread, which is perfectly fine. But which also leave the possiblity
> open to execute your real-time script in the EE of the deployment component,
> associated with a RT activity (hence confirming its role as "supervisor").

BTW (and maybe this proves the usefulness of my previous note): In the
"orocos 2.0 design" I sketched earlier in this thread, this would not
be possible anymore. The deployment component would then *really* be
a non-realtime (i.e. connected to a non-realtime activity, that would
load the .so's for instance) component, and Rubens original statement

Adding a realtime activity for script execution to the highly non realtime
deployment component does not bring you into trouble?

would then perfectly make sense!

Klaas

[Bug 562] Deployable empty TaskContext

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