New 1.10 TaskContext execution model

Hi,

>From reading the 1.10 changelog <http://www.orocos.org/stable/documentation/rtt/v1.10.x/doc-xml/orocos-rtt-changes.html>, I understand that creating a taskContext will now automatically create a thread (using default cmake options).

Now, as far as I understand the API documentation, the suggested approach to goto Periodic mode

<quote>
this->getActivity()->setPeriod(0.001)
</quote>

in the above changelog cannot even work, since

this->getActivity(), returns an ActivityInterface <http://www.orocos.org/stable/documentation/rtt/v1.10.x/api/html/classRTT_1_1ActivityInterface.html>, which has no member setPeriod().

What am I missing here?

Klaas

New 1.10 TaskContext execution model

On Mon, Oct 26, 2009 at 12:09, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
> Hi,
>
> >From reading the 1.10 changelog <http://www.orocos.org/stable/documentation/rtt/v1.10.x/doc-xml/orocos-rtt-changes.html>, I understand that creating a taskContext will now automatically create a thread (using default cmake options).
>
> Now, as far as I understand the API documentation, the suggested approach to goto Periodic mode
>
> <quote>
> this->getActivity()->setPeriod(0.001)
> </quote>
>
> in the above changelog cannot even work, since
>
> this->getActivity(), returns an ActivityInterface <http://www.orocos.org/stable/documentation/rtt/v1.10.x/api/html/classRTT_1_1ActivityInterface.html>, which has no member setPeriod().
>
> What am I missing here?

Damn. Just when you think you got it right...
&#10;this-&gt;getActivity()-&gt;thread()-&gt;setPeriod(0.001)&#10;
will work for you. The setPeriod() function was added to the
ThreadInterface, but not to the ActivityInterface. I think it will
stay like that, but it doesn't look very user friendly.

Probably a this->setPeriod(0.001) helper is due in place... thoughts ?

Peter

New 1.10 TaskContext execution model

On Mon, 26 Oct 2009, Peter Soetens wrote:
> On Mon, Oct 26, 2009 at 12:09, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
>> Hi,
>>
>>> From reading the 1.10 changelog <http://www.orocos.org/stable/documentation/rtt/v1.10.x/doc-xml/orocos-rtt-changes.html>, I understand that creating a taskContext will now automatically create a thread (using default cmake options).
>>
>> Now, as far as I understand the API documentation, the suggested approach to goto Periodic mode
>>
>> <quote>
>> this->getActivity()->setPeriod(0.001)
>> </quote>
>>
>> in the above changelog cannot even work, since
>>
>> this->getActivity(), returns an ActivityInterface <http://www.orocos.org/stable/documentation/rtt/v1.10.x/api/html/classRTT_1_1ActivityInterface.html>, which has no member setPeriod().
>>
>> What am I missing here?
>
> Damn. Just when you think you got it right...
> &#10;&gt; this-&gt;getActivity()-&gt;thread()-&gt;setPeriod(0.001)&#10;&gt;
> will work for you. The setPeriod() function was added to the
> ThreadInterface, but not to the ActivityInterface. I think it will
> stay like that, but it doesn't look very user friendly.
>
> Probably a this->setPeriod(0.001) helper is due in place... thoughts ?

Asking me for thoughts must be st. like opening pandora's box :-)

I had worked around it using a dynamic_cast, but I would hardly call
that more "user friendly" :-)

While I always have been a strong proponent of coupling taskcontext
and its activity more tightly together,

- Using the scheme you suggest above, one will always get "harmless" warnings,
e.g. consider following code (don't mention the dynamic casts):

&#10;   Universe universe(&quot;Universe&quot;);&#10;   dynamic_cast&lt;RTT::Activity *&gt;(universe.getActivity())-&gt;setScheduler(ORO_SCHED_RT);&#10;   dynamic_cast&lt;RTT::Activity *&gt;(universe.getActivity())-&gt;setPriority(99);&#10;  

results in

0.004 [ Info ][Thread::setScheduler] Setting scheduler type for
Thread 'Activity' to 1
0.004 [ Warning][Thread::setScheduler] Forcing priority (0) of thread
with !SCHED_OTHER policy to 1.

"Perfectly logical" if you know how it's done, but imagine you're an
orocos newbie. Using the

&#10;   taskcontext tc;&#10;   tc.setActivity(new Activity (...));&#10;  

might be a way to avoid these.

- I didn't check the component builders manual, but the new activity
model has huge impact on legacy code. While I looked at the 1.10
changelog before coding, I never realised that a legacy 1.6
application using 4 threads (main + 3 taskcontexts) would still
compile, but end up using 7 threads.

&#10;   taskcontext tc;&#10;   PeriodicActivity ac( blabla, tc.engine());&#10;  

Maybe it's good to mention this somewhat more explicitly in the docs
<wink>
(otherwise some of those legacy applications might be running out-of-ram
_without_ using O(1) RT dynamic memory allocation :-P
</wink>

Klaas

New 1.10 TaskContext execution model

On Mon, Oct 26, 2009 at 4:01 PM, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
> On Mon, 26 Oct 2009, Peter Soetens wrote:
>> On Mon, Oct 26, 2009 at 12:09, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
>>> Hi,
>>>
>>>> From reading the 1.10 changelog <http://www.orocos.org/stable/documentation/rtt/v1.10.x/doc-xml/orocos-rtt-changes.html>, I understand that creating a taskContext will now automatically create a thread (using default cmake options).
>>>
>>> Now, as far as I understand the API documentation, the suggested approach to goto Periodic mode
>>>
>>> <quote>
>>> this->getActivity()->setPeriod(0.001)
>>> </quote>
>>>
>>> in the above changelog cannot even work, since
>>>
>>> this->getActivity(), returns an ActivityInterface <http://www.orocos.org/stable/documentation/rtt/v1.10.x/api/html/classRTT_1_1ActivityInterface.html>, which has no member setPeriod().
>>>
>>> What am I missing here?
>>
>> Damn. Just when you think you got it right...
>> &#10;&gt;&gt; this-&gt;getActivity()-&gt;thread()-&gt;setPeriod(0.001)&#10;&gt;&gt;
>> will work for you. The setPeriod() function was added to the
>> ThreadInterface, but not to the ActivityInterface. I think it will
>> stay like that, but it doesn't look very user friendly.
>>
>> Probably a this->setPeriod(0.001) helper is due in place... thoughts ?
>
> Asking me for thoughts must be st. like opening pandora's box :-)
>
> I had worked around it using a dynamic_cast, but I would hardly call
> that more "user friendly" :-)
>
> While I always have been a strong proponent of coupling taskcontext
> and its activity more tightly together,
>
> - Using the scheme you suggest above, one will always get "harmless" warnings,
>   e.g. consider following code (don't mention the dynamic casts):
>
>   &#10;&gt;   Universe universe(&quot;Universe&quot;);&#10;&gt;   dynamic_cast&lt;RTT::Activity *&gt;(universe.getActivity())-&gt;setScheduler(ORO_SCHED_RT);&#10;&gt;   dynamic_cast&lt;RTT::Activity *&gt;(universe.getActivity())-&gt;setPriority(99);&#10;&gt;  
>
>   results in
>
>   0.004 [ Info   ][Thread::setScheduler] Setting scheduler type for
>   Thread 'Activity' to 1
>   0.004 [ Warning][Thread::setScheduler] Forcing priority (0) of thread
>   with !SCHED_OTHER policy to 1.
>
>   "Perfectly logical" if you know how it's done, but imagine you're an
>   orocos newbie.  Using the
>
>   &#10;&gt;   taskcontext tc;&#10;&gt;   tc.setActivity(new Activity (...));&#10;&gt;  
>
>   might be a way to avoid these.

It is not, BTW (Well, it avoid these but creates new ones :-)
Have you thought about adding constructor arguments to TaskContext
(with default values for legacy compliance)?

Klaas

> - I didn't check the component builders manual, but the new activity
>   model has huge impact on legacy code.  While I looked at the 1.10
>   changelog before coding, I never realised that a legacy 1.6
>   application using 4 threads (main + 3 taskcontexts) would still
>   compile, but end up using 7 threads.
>
>   &#10;&gt;   taskcontext tc;&#10;&gt;   PeriodicActivity ac( blabla, tc.engine());&#10;&gt;  
>
>   Maybe it's good to mention this somewhat more explicitly in the docs
>   <wink>
>   (otherwise some of those legacy applications might be running out-of-ram
>   _without_ using O(1) RT dynamic memory allocation :-P
>   </wink>

New 1.10 TaskContext execution model

On Mon, Oct 26, 2009 at 17:29, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
> On Mon, Oct 26, 2009 at 4:01 PM, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
>> On Mon, 26 Oct 2009, Peter Soetens wrote:
>>> On Mon, Oct 26, 2009 at 12:09, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
>>>> Hi,
>>>>
>>>>> From reading the 1.10 changelog <http://www.orocos.org/stable/documentation/rtt/v1.10.x/doc-xml/orocos-rtt-changes.html>, I understand that creating a taskContext will now automatically create a thread (using default cmake options).
>>>>
>>>> Now, as far as I understand the API documentation, the suggested approach to goto Periodic mode
>>>>
>>>> <quote>
>>>> this->getActivity()->setPeriod(0.001)
>>>> </quote>
>>>>
>>>> in the above changelog cannot even work, since
>>>>
>>>> this->getActivity(), returns an ActivityInterface <http://www.orocos.org/stable/documentation/rtt/v1.10.x/api/html/classRTT_1_1ActivityInterface.html>, which has no member setPeriod().
>>>>
>>>> What am I missing here?
>>>
>>> Damn. Just when you think you got it right...
>>> &#10;&gt;&gt;&gt; this-&gt;getActivity()-&gt;thread()-&gt;setPeriod(0.001)&#10;&gt;&gt;&gt;
>>> will work for you. The setPeriod() function was added to the
>>> ThreadInterface, but not to the ActivityInterface. I think it will
>>> stay like that, but it doesn't look very user friendly.
>>>
>>> Probably a this->setPeriod(0.001) helper is due in place... thoughts ?
>>
>> Asking me for thoughts must be st. like opening pandora's box :-)
>>
>> I had worked around it using a dynamic_cast, but I would hardly call
>> that more "user friendly" :-)
>>
>> While I always have been a strong proponent of coupling taskcontext
>> and its activity more tightly together,
>>
>> - Using the scheme you suggest above, one will always get "harmless" warnings,
>>   e.g. consider following code (don't mention the dynamic casts):
>>
>>   &#10;&gt;&gt;   Universe universe(&quot;Universe&quot;);&#10;&gt;&gt;   dynamic_cast&lt;RTT::Activity *&gt;(universe.getActivity())-&gt;setScheduler(ORO_SCHED_RT);&#10;&gt;&gt;   dynamic_cast&lt;RTT::Activity *&gt;(universe.getActivity())-&gt;setPriority(99);&#10;&gt;&gt;  
>>
>>   results in
>>
>>   0.004 [ Info   ][Thread::setScheduler] Setting scheduler type for
>>   Thread 'Activity' to 1
>>   0.004 [ Warning][Thread::setScheduler] Forcing priority (0) of thread
>>   with !SCHED_OTHER policy to 1.
>>
>>   "Perfectly logical" if you know how it's done, but imagine you're an
>>   orocos newbie.  Using the
>>
>>   &#10;&gt;&gt;   taskcontext tc;&#10;&gt;&gt;   tc.setActivity(new Activity (...));&#10;&gt;&gt;  
>>
>>   might be a way to avoid these.
>
> It is not, BTW (Well, it avoid these but creates new ones :-)
> Have you thought about adding constructor arguments to TaskContext
> (with default values for legacy compliance)?
>

Not really (yet). The first thing we need is some unit tests that test
this API as it was meant. If there are then still problems in
flexibility, we can extend it.

Peter