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