On May 11, 2011, at 07:20 , Willy Lambert wrote:

>
>
> 2011/5/11 Markus Klotzbuecher <markus [dot] klotzbuecher [..] ...>
> On Wed, May 11, 2011 at 09:58:00AM +0200, Peter Soetens wrote:
> > On Wednesday 11 May 2011 09:23:00 Peter Soetens wrote:
> > > On Tuesday 10 May 2011 14:07:56 b [dot] willems [..] ... wrote:
> > > > Hi everybody,
> > > >
> > > > When I started using Orocos I remember the stophook of the components
> > > > being executing upon quiting from the Deployer (by just entering quit).
> > > > For some of my components it is essential that this happens (think about
> > > > disabling amplifiers etc). However this doesn't happen anymore. That is,
> > > > before quiting from the Deployer I first have to manually execute some
> > > > stophooks. Did things change within Orocos or is this just me?
> > >
> > > Kicking out stopped working for non-xml loads since Stephen's patches were
> > > merged. I overlooked this side effect. I'll merge a fix asap.
> >
> > I have pushed&tested the fix on the toolchain-2.3 branch. I also supported
> > kickOutCompnent("foo") for a component not loaded using XML (for mk-
> > happiness!).
>
> Yuhu! I'm already feeling much happier!
>
> :-)
>
> An interesting features of the deployer could be to have a "stop script" option. In this way we could ask the deployer to run an undeployer script on the quit command. This could be usefull to application that need fings to be cleared in order (I mean stop decisions processes before hardware processes to ensure smart deceleration on coupled motors for example).

We need something like this, as does anyone (in reality) that makes extensive use of state machines. The fact that "quit" just starts stopping components, rather than triggering an ordered shutdown (as specified by the application) is a real PITA. Our deployer's fail to stop cleanly perhaps 1/3rd of the time ... just not something we've gotten to fixing ...

Not sure if I would go with a "stop script", or a "stop method" that the deployer exposes that applications could connect to, or something similar. Needs discussion ...

> An intermediate features could be to deploy things in the opposite order as they where deployed.

This doesn't necessarily solve the problem in a complex system, though it would be a step in the right direction. Stopping our applications often requires changing states in several state machines that manage hardware, before we begin to start stopping components themselves. This is obviously application dependant ...

S