[Rock-dev] Regarding dynamic properties

[Sylvain Joyeux]

On Thursday, January 09, 2014 10:13:05 AM Matthias Goldhoorn wrote:
> On 09.01.2014 09:52, Sylvain Joyeux wrote:
> > The separation between the internal method called in caller thread and the
> > user method in callee thread looks overkill.
> Other suggestions?
Do the simple thing: one operation in component thread that simply calls the 
user method.

> >   - when the component is not running, there can be no lock contention
> >     that
> >     blocks the caller for a long period of time (the component is doing
> >     nothing). Even if it was the case, one can call operations
> >     asynchronously.
> 
> Don't get this, i assume that you mean the task could not block if it's
> not running. If the deployed task uses the task-scheduler, then behavior was 
> indeed that the task blocks because it's not executed at all.
> This causes the normal configuration methods (throught syskit/orocos.rb)
> to hang.
Then *this* is what needs to be fixed. Not being able to call operations on all 
tasks is problematic *in itself*. Working around it here, given the complexity 
it introduces, makes no sense to me.

In any case: you MUST do the checks in component thread because of the race 
condition (or add even more complexity).

> > Quick code review:
> >   - you introduce a change of behaviour in argument_signature: you add
> >   either a>   
> >     leading or trailing space in the returned string if one of the with_
> >     parameters are false.
> 
> which should make no difference?! (could use strip otherwise)
Why not ? Don't change the return value of a  method "just because you believe 
it won't matter" !

> > Finally, I did not get the change of interface for the user method(s), and
> > why it was necessary
> 
> Before there was a call to the base-class implementation done, the base
> function is now not needed anymore because the property get's updates by
> the internal function. So the user-code could simply return true which
> makes the core more straight forward.
You still need to call the base method as you might have a superclass (in 
which the operation's method might be implemented). It is just simpler to have 
a method returning true generated in the base class and make all generated 
user methods call it.
-- 
 Dr. Ing. Sylvain Joyeux
 Space and Security Robotics
 
 Besuchsadresse der Nebengeschäftstelle:
 DFKI GmbH
 Robotics Innovation Center
 Robert-Hooke-Straße 5
 28359 Bremen, Germany
 
 Postadresse der Hauptgeschäftsstelle Standort Bremen:
 DFKI GmbH
 Robotics Innovation Center
 Robert-Hooke-Straße 1
 28359 Bremen, Germany 

 Phone:     +49 421 178 45-4136
 Zentrale: +49 421 178 45-0
 Fax:           +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
 E-Mail:     sylvain.joyeux at dfki.de
 
 Weitere Informationen: http://www.dfki.de/robotik
 -----------------------------------------------------------------------
 Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
 Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
 Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster 
 (Vorsitzender) Dr. Walter Olthoff
 Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
 Amtsgericht Kaiserslautern, HRB 2313
 Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
 USt-Id.Nr.:    DE 148646973
 Steuernummer:  19/673/0060/3 
 ---------------------------------------------------------------------