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: [email protected] Weitere Informationen: http://www.informatik.uni-bremen.de/robotik _______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
