[Rock-dev] Regarding dynamic properties

[Matthias Goldhoorn]

On 20.12.2013 10:35, Sylvain Joyeux wrote:
> On Tuesday, December 17, 2013 01:18:52 PM Matthias Goldhoorn wrote:
>> They are quite stables so far, expect:
>> they are in the end thought orocos.rb RPC (operations) on the task.
>> The problem here is if, the underlying task is not (yet) running the
>> often setting something on not-yet initialized members. This could be
>> checked within the task, but i still find this ugly.
>>
>> I would prefer that:
>> - the operation get's called if the task was already configured
>> - the normal property get's set if the task is not (yet) configured
>> - Syskit get's hang if the operation is called
>>
>> Each user then (which is normally the case) has to check during
>> configuration time the value of the property.
>>
>> Thoughts?
> I completely agree that this is a problem, and on the general solution (i.e.
> that the property should be written if the task is not started yet and call
> the user's setXXX method only if the task is running).
>
> However, I would not do that in orocos.rb, but in the generated code:
>   - have a specialized virtual method (e.g. __orogen__setExposure) that is
>     the one called by the operation
>   - have this method either set the property or call the user-provided virtual
>     method (which would be still called setExposure) depending on the task's
>    state
>   - we would need to know in which hook the property gets applied (in
>    configureHook or  startHook) to decide whether the set method should be
>    called as soon as the  task is configured or only if it is running. By
>    default, I would say  "configureHook". This would anyways be great for
>    syskit: we could avoid fully  reconfiguring the task in cases only a
>    stop/start cycle is needed.
Does syskit then allow calls to the remote task-context even they are 
(currently) not running?.
In the past syskit stats to hang. If you taking care about this. I can 
implemend the behaviour next year.

Regarding the "when", should this be specified at the orogen-definition 
or should be there onlya fixed point.
I would vote for the following behaviour:

- case task-stopped (pre-operational):
The normal property object get's written throught the invisible setter 
AND the user has to make sure that either the property get's read or he 
calls "updateDynamicProperties()" from a hook he prefer.

- case task-configured (stopped):
the normal user-setter function get's called, and if this does not fit 
the user-requierement he has to ignore the value from the setter funtion 
and access it manually in the start-hook (therefore no config in 
configure hook is needed (or optional))

- case task-running (running):
normal user-setter at all

 From Syskit point:
syskit does not need to take care about restarting if ONLY a dynamic 
prop get's change. Simply call the setter operation without restarting 
the task-instance.


>
> The reasons for that are:
>   - testing whether a task is running from outside the task's thread is
>    asynchronous. The task could have e.g. stopped between the time you check
>    and  the time the operation is processed.
>   - it makes orocos.rb complex and the dynamic property stuff an orocos.rb-
>    specific thing (I would like to avoid that)
>   - the 'most-synchronous' way to test whether a task is running involves a
>    CORBA call, i.e. costly.
>


-- 
  Dipl.-Inf. Matthias Goldhoorn
  Space and Underwater Robotic

  Universität Bremen
  FB 3 - Mathematik und Informatik
  AG Robotik
  Robert-Hooke-Straße 1
  28359 Bremen, Germany
  
  Zentrale: +49 421 178 45-6611
  
  Besuchsadresse der Nebengeschäftstelle:
  Robert-Hooke-Straße 5
  28359 Bremen, Germany
  
  Tel.:    +49 421 178 45-4193
  Empfang: +49 421 178 45-6600
  Fax:     +49 421 178 45-4150
  E-Mail:  matthias.goldhoorn at informatik.uni-bremen.de

  Weitere Informationen: http://www.informatik.uni-bremen.de/robotik