When the user quits a deployer by typing "quit" or using Ctrl-D, the deployer just stops all components and exits. This is a problem for any state machines that need to shutdown gracefully; they aren't notified of the impending shutdown and instead the component itself is stopped (preventing the state machine running).
We've got a patch to the v1 deployment component and deployers that supports running an (optional) command before the deployment component starts shutting down components. This allows an application-specific shutdown sequence, including (but not limited to) graceful shutdown of any state machines (aka Coordinators).
I think that this functionality will forward port to the v2 deployers very easily, but I'm just wondering if anyone is interested before I put the effort in?
Cheers
S
Support clean deployer shutdown
On Wed, Jun 06, 2012 at 10:23:01AM -0400, S Roderick wrote:
> When the user quits a deployer by typing "quit" or using Ctrl-D, the deployer just stops all components and exits. This is a problem for any state machines that need to shutdown gracefully; they aren't notified of the impending shutdown and instead the component itself is stopped (preventing the state machine running).
>
> We've got a patch to the v1 deployment component and deployers that supports running an (optional) command before the deployment component starts shutting down components. This allows an application-specific shutdown sequence, including (but not limited to) graceful shutdown of any state machines (aka Coordinators).
>
> I think that this functionality will forward port to the v2
> deployers very easily, but I'm just wondering if anyone is
> interested before I put the effort in?
Yes, definitely. How did you implement it? For my purposes the
deployment component would raise an event (like "e_system_shutdown")
on a port that a Coordinator can react to.
Markus
Support clean deployer shutdown
On Jun 6, 2012, at 10:33 , Markus Klotzbuecher wrote:
> On Wed, Jun 06, 2012 at 10:23:01AM -0400, S Roderick wrote:
>> When the user quits a deployer by typing "quit" or using Ctrl-D, the deployer just stops all components and exits. This is a problem for any state machines that need to shutdown gracefully; they aren't notified of the impending shutdown and instead the component itself is stopped (preventing the state machine running).
>>
>> We've got a patch to the v1 deployment component and deployers that supports running an (optional) command before the deployment component starts shutting down components. This allows an application-specific shutdown sequence, including (but not limited to) graceful shutdown of any state machines (aka Coordinators).
>>
>> I think that this functionality will forward port to the v2
>> deployers very easily, but I'm just wondering if anyone is
>> interested before I put the effort in?
>
> Yes, definitely. How did you implement it? For my purposes the
> deployment component would raise an event (like "e_system_shutdown")
> on a port that a Coordinator can react to.
The deployment component calls a command in a peer component (if the peer and command exist). This command can take as long as necessary to return, allowing the system to shut itself down. With an event, what do you wait on to determine that shutdown has completed? The deployment component can also time out on the command, and uses optional properties in the Deployer itself that specify these time out parameters.
We created an application-specific peer component that contains that command (an exported function in a loaded script), which does the actual work. This command returns when the system has completed shutdown (or times out, if some piece of hardware locks up).
HTH
S
Support clean deployer shutdown
2012/6/6 Stephen Roderick <kiwi [dot] net [..] ...>
> On Jun 6, 2012, at 10:33 , Markus Klotzbuecher wrote:
>
> > On Wed, Jun 06, 2012 at 10:23:01AM -0400, S Roderick wrote:
> >> When the user quits a deployer by typing "quit" or using Ctrl-D, the
> deployer just stops all components and exits. This is a problem for any
> state machines that need to shutdown gracefully; they aren't notified of
> the impending shutdown and instead the component itself is stopped
> (preventing the state machine running).
> >>
> >> We've got a patch to the v1 deployment component and deployers that
> supports running an (optional) command before the deployment component
> starts shutting down components. This allows an application-specific
> shutdown sequence, including (but not limited to) graceful shutdown of any
> state machines (aka Coordinators).
> >>
> >> I think that this functionality will forward port to the v2
> >> deployers very easily, but I'm just wondering if anyone is
> >> interested before I put the effort in?
> >
> > Yes, definitely. How did you implement it? For my purposes the
> > deployment component would raise an event (like "e_system_shutdown")
> > on a port that a Coordinator can react to.
>
> The deployment component calls a command in a peer component (if the peer
> and command exist). This command can take as long as necessary to return,
> allowing the system to shut itself down. With an event, what do you wait on
> to determine that shutdown has completed?
I don't think this information is always relevant. I mean, you want to let
a chance to the system to shutdown properly in a certain delay. But you
don't always want to wait ages that a non critical component (maybe) wants
to shutdown.
IMO, publishing something in a port, and waiting a certain delay (a
properties ? configured to 0 for unlimited delay ?) that an input port
(=event) comes with "e_completed_shutdown" has come.
The generation of the "e_completed_shutdown" depends on every application
since you can have non critical components that you don't even want to wait
(but they will receive the "e_system_shutdown" and try to do so)
> The deployment component can also time out on the command, and uses
> optional properties in the Deployer itself that specify these time out
> parameters.
>
> We created an application-specific peer component that contains that
> command (an exported function in a loaded script), which does the actual
> work. This command returns when the system has completed shutdown (or times
> out, if some piece of hardware locks up).
>
> HTH
> S
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
Support clean deployer shutdown
On Jun 6, 2012, at 13:59 , Willy Lambert wrote:
>
>
> 2012/6/6 Stephen Roderick <kiwi [dot] net [..] ...>
> On Jun 6, 2012, at 10:33 , Markus Klotzbuecher wrote:
>
> > On Wed, Jun 06, 2012 at 10:23:01AM -0400, S Roderick wrote:
> >> When the user quits a deployer by typing "quit" or using Ctrl-D, the deployer just stops all components and exits. This is a problem for any state machines that need to shutdown gracefully; they aren't notified of the impending shutdown and instead the component itself is stopped (preventing the state machine running).
> >>
> >> We've got a patch to the v1 deployment component and deployers that supports running an (optional) command before the deployment component starts shutting down components. This allows an application-specific shutdown sequence, including (but not limited to) graceful shutdown of any state machines (aka Coordinators).
> >>
> >> I think that this functionality will forward port to the v2
> >> deployers very easily, but I'm just wondering if anyone is
> >> interested before I put the effort in?
> >
> > Yes, definitely. How did you implement it? For my purposes the
> > deployment component would raise an event (like "e_system_shutdown")
> > on a port that a Coordinator can react to.
>
> The deployment component calls a command in a peer component (if the peer and command exist). This command can take as long as necessary to return, allowing the system to shut itself down. With an event, what do you wait on to determine that shutdown has completed?
>
> I don't think this information is always relevant. I mean, you want to let a chance to the system to shutdown properly in a certain delay. But you don't always want to wait ages that a non critical component (maybe) wants to shutdown.
>
> IMO, publishing something in a port, and waiting a certain delay (a properties ? configured to 0 for unlimited delay ?) that an input port (=event) comes with "e_completed_shutdown" has come.
>
> The generation of the "e_completed_shutdown" depends on every application since you can have non critical components that you don't even want to wait (but they will receive the "e_system_shutdown" and try to do so)
You've just described our implementation.
After the taskbrowser quits in the deployer (due to "quit" or Ctrl-D), the deployment component checks for a certain command in a certain peer. If that peer and command exists then it runs that command. That command may do whatever it likes, and may take as long or short as it likes (this is application specific). The deployment component will timeout on the command at some point, but again, this is application specific.
One of our applications does what you say - the shutdown command triggers graceful shut downs of several (but not all, they're not all critical) coordinator components, and waits (with another timeout) on the final piece of hardware to shutdown. Then the command returns, and the deployer quits gracefully.
HTH
S
Support clean deployer shutdown
On Wed, Jun 06, 2012 at 10:40:30AM -0400, Stephen Roderick wrote:
> On Jun 6, 2012, at 10:33 , Markus Klotzbuecher wrote:
>
> > On Wed, Jun 06, 2012 at 10:23:01AM -0400, S Roderick wrote:
> >> When the user quits a deployer by typing "quit" or using Ctrl-D, the deployer just stops all components and exits. This is a problem for any state machines that need to shutdown gracefully; they aren't notified of the impending shutdown and instead the component itself is stopped (preventing the state machine running).
> >>
> >> We've got a patch to the v1 deployment component and deployers that supports running an (optional) command before the deployment component starts shutting down components. This allows an application-specific shutdown sequence, including (but not limited to) graceful shutdown of any state machines (aka Coordinators).
> >>
> >> I think that this functionality will forward port to the v2
> >> deployers very easily, but I'm just wondering if anyone is
> >> interested before I put the effort in?
> >
> > Yes, definitely. How did you implement it? For my purposes the
> > deployment component would raise an event (like "e_system_shutdown")
> > on a port that a Coordinator can react to.
>
> The deployment component calls a command in a peer component (if the
> peer and command exist). This command can take as long as necessary
Ok. Do you instrument "quit" or catch Ctrl-C?
> to return, allowing the system to shut itself down. With an event,
> what do you wait on to determine that shutdown has completed? The
A response event?
> deployment component can also time out on the command, and uses
> optional properties in the Deployer itself that specify these time
> out parameters.
That's nice!
> We created an application-specific peer component that contains that
> command (an exported function in a loaded script), which does the
> actual work. This command returns when the system has completed
> shutdown (or times out, if some piece of hardware locks up).
Ok, I could use that as an "mediator" to raise my events...
I've also been wanting something mechanism like that for rttlua-* in
order to save the history upon quit...
Markus
Support clean deployer shutdown
On Jun 6, 2012, at 10:55 , Markus Klotzbuecher wrote:
> On Wed, Jun 06, 2012 at 10:40:30AM -0400, Stephen Roderick wrote:
>> On Jun 6, 2012, at 10:33 , Markus Klotzbuecher wrote:
>>
>>> On Wed, Jun 06, 2012 at 10:23:01AM -0400, S Roderick wrote:
>>>> When the user quits a deployer by typing "quit" or using Ctrl-D, the deployer just stops all components and exits. This is a problem for any state machines that need to shutdown gracefully; they aren't notified of the impending shutdown and instead the component itself is stopped (preventing the state machine running).
>>>>
>>>> We've got a patch to the v1 deployment component and deployers that supports running an (optional) command before the deployment component starts shutting down components. This allows an application-specific shutdown sequence, including (but not limited to) graceful shutdown of any state machines (aka Coordinators).
>>>>
>>>> I think that this functionality will forward port to the v2
>>>> deployers very easily, but I'm just wondering if anyone is
>>>> interested before I put the effort in?
>>>
>>> Yes, definitely. How did you implement it? For my purposes the
>>> deployment component would raise an event (like "e_system_shutdown")
>>> on a port that a Coordinator can react to.
>>
>> The deployment component calls a command in a peer component (if the
>> peer and command exist). This command can take as long as necessary
>
> Ok. Do you instrument "quit" or catch Ctrl-C?
No. Just wait for the TaskBrowser to exit in bin/deployer-xxx.cpp. Much easier.
>> to return, allowing the system to shut itself down. With an event,
>> what do you wait on to determine that shutdown has completed? The
>
> A response event?
That is another approach, yes.
>> deployment component can also time out on the command, and uses
>> optional properties in the Deployer itself that specify these time
>> out parameters.
>
> That's nice!
Yeah, makes life much easier for various applications that need different parameterization. I think that this paradigm, or something like it, should be used more pervasively within Orocos as a whole to allow application-specific parameterization of the Orocos internals themselves. The ORO_LOGLEVEL environment variable is a similar paradigm.
>> We created an application-specific peer component that contains that
>> command (an exported function in a loaded script), which does the
>> actual work. This command returns when the system has completed
>> shutdown (or times out, if some piece of hardware locks up).
>
> Ok, I could use that as an "mediator" to raise my events...
> I've also been wanting something mechanism like that for rttlua-* in
> order to save the history upon quit...
Might work for that.
I'll try the forward port and post if it goes well.
S
Support clean deployer shutdown
To hopefully save me some time, can someone please point the way in converting the following v1 code, to v2:
What are RTT::Commands now?
Cheers
S
On Jun 6, 2012, at 10:59 , Stephen Roderick wrote:
> On Jun 6, 2012, at 10:55 , Markus Klotzbuecher wrote:
>
>> On Wed, Jun 06, 2012 at 10:40:30AM -0400, Stephen Roderick wrote:
>>> On Jun 6, 2012, at 10:33 , Markus Klotzbuecher wrote:
>>>
>>>> On Wed, Jun 06, 2012 at 10:23:01AM -0400, S Roderick wrote:
>>>>> When the user quits a deployer by typing "quit" or using Ctrl-D, the deployer just stops all components and exits. This is a problem for any state machines that need to shutdown gracefully; they aren't notified of the impending shutdown and instead the component itself is stopped (preventing the state machine running).
>>>>>
>>>>> We've got a patch to the v1 deployment component and deployers that supports running an (optional) command before the deployment component starts shutting down components. This allows an application-specific shutdown sequence, including (but not limited to) graceful shutdown of any state machines (aka Coordinators).
>>>>>
>>>>> I think that this functionality will forward port to the v2
>>>>> deployers very easily, but I'm just wondering if anyone is
>>>>> interested before I put the effort in?
>>>>
>>>> Yes, definitely. How did you implement it? For my purposes the
>>>> deployment component would raise an event (like "e_system_shutdown")
>>>> on a port that a Coordinator can react to.
>>>
>>> The deployment component calls a command in a peer component (if the
>>> peer and command exist). This command can take as long as necessary
>>
>> Ok. Do you instrument "quit" or catch Ctrl-C?
>
> No. Just wait for the TaskBrowser to exit in bin/deployer-xxx.cpp. Much easier.
>
>>> to return, allowing the system to shut itself down. With an event,
>>> what do you wait on to determine that shutdown has completed? The
>>
>> A response event?
>
> That is another approach, yes.
>
>>> deployment component can also time out on the command, and uses
>>> optional properties in the Deployer itself that specify these time
>>> out parameters.
>>
>> That's nice!
>
> Yeah, makes life much easier for various applications that need different parameterization. I think that this paradigm, or something like it, should be used more pervasively within Orocos as a whole to allow application-specific parameterization of the Orocos internals themselves. The ORO_LOGLEVEL environment variable is a similar paradigm.
>
>>> We created an application-specific peer component that contains that
>>> command (an exported function in a loaded script), which does the
>>> actual work. This command returns when the system has completed
>>> shutdown (or times out, if some piece of hardware locks up).
>>
>> Ok, I could use that as an "mediator" to raise my events...
>> I've also been wanting something mechanism like that for rttlua-* in
>> order to save the history upon quit...
>
> Might work for that.
>
> I'll try the forward port and post if it goes well.
> S
>
Support clean deployer shutdown
2012/6/6 S Roderick <kiwi [dot] net [..] ...>
> To hopefully save me some time, can someone please point the way in
> converting the following v1 code, to v2:
>
>
>
> What are RTT::Commands now?
>
OwnerThread Operation ?
>
> Cheers
> S
>
> On Jun 6, 2012, at 10:59 , Stephen Roderick wrote:
>
> > On Jun 6, 2012, at 10:55 , Markus Klotzbuecher wrote:
> >
> >> On Wed, Jun 06, 2012 at 10:40:30AM -0400, Stephen Roderick wrote:
> >>> On Jun 6, 2012, at 10:33 , Markus Klotzbuecher wrote:
> >>>
> >>>> On Wed, Jun 06, 2012 at 10:23:01AM -0400, S Roderick wrote:
> >>>>> When the user quits a deployer by typing "quit" or using Ctrl-D, the
> deployer just stops all components and exits. This is a problem for any
> state machines that need to shutdown gracefully; they aren't notified of
> the impending shutdown and instead the component itself is stopped
> (preventing the state machine running).
> >>>>>
> >>>>> We've got a patch to the v1 deployment component and deployers that
> supports running an (optional) command before the deployment component
> starts shutting down components. This allows an application-specific
> shutdown sequence, including (but not limited to) graceful shutdown of any
> state machines (aka Coordinators).
> >>>>>
> >>>>> I think that this functionality will forward port to the v2
> >>>>> deployers very easily, but I'm just wondering if anyone is
> >>>>> interested before I put the effort in?
> >>>>
> >>>> Yes, definitely. How did you implement it? For my purposes the
> >>>> deployment component would raise an event (like "e_system_shutdown")
> >>>> on a port that a Coordinator can react to.
> >>>
> >>> The deployment component calls a command in a peer component (if the
> >>> peer and command exist). This command can take as long as necessary
> >>
> >> Ok. Do you instrument "quit" or catch Ctrl-C?
> >
> > No. Just wait for the TaskBrowser to exit in bin/deployer-xxx.cpp. Much
> easier.
> >
> >>> to return, allowing the system to shut itself down. With an event,
> >>> what do you wait on to determine that shutdown has completed? The
> >>
> >> A response event?
> >
> > That is another approach, yes.
> >
> >>> deployment component can also time out on the command, and uses
> >>> optional properties in the Deployer itself that specify these time
> >>> out parameters.
> >>
> >> That's nice!
> >
> > Yeah, makes life much easier for various applications that need
> different parameterization. I think that this paradigm, or something like
> it, should be used more pervasively within Orocos as a whole to allow
> application-specific parameterization of the Orocos internals themselves.
> The ORO_LOGLEVEL environment variable is a similar paradigm.
> >
> >>> We created an application-specific peer component that contains that
> >>> command (an exported function in a loaded script), which does the
> >>> actual work. This command returns when the system has completed
> >>> shutdown (or times out, if some piece of hardware locks up).
> >>
> >> Ok, I could use that as an "mediator" to raise my events...
> >> I've also been wanting something mechanism like that for rttlua-* in
> >> order to save the history upon quit...
> >
> > Might work for that.
> >
> > I'll try the forward port and post if it goes well.
> > S
> >
> > --
> > Orocos-Dev mailing list
> > Orocos-Dev [..] ...
> > http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
Support clean deployer shutdown
On Jun 6, 2012, at 15:21 , Willy Lambert wrote:
>
>
> 2012/6/6 S Roderick <kiwi [dot] net [..] ...>
> To hopefully save me some time, can someone please point the way in converting the following v1 code, to v2:
>
>
>
> What are RTT::Commands now?
>
>
> OwnerThread Operation ?
Thanks, that helped.
Attached are patches for the toolchain-2.5 branch of OCL. They compile clean, and the deployer runs, but I can't test it beyond that. I've also attached an example deployment XML file, and a primitive shutdown script to demonstrate that side of thins. I know that this approach works in v1, but I'm sure there are some issues with it in v2.
HTH
S
Support clean deployer shutdown
On Wed, Jun 6, 2012 at 9:15 PM, Stephen Roderick <kiwi [dot] net [..] ...> wrote:
> On Jun 6, 2012, at 15:21 , Willy Lambert wrote:
>
> >
> >
> > 2012/6/6 S Roderick <kiwi [dot] net [..] ...>
> > To hopefully save me some time, can someone please point the way in
> converting the following v1 code, to v2:
> >
> >
> >
> > What are RTT::Commands now?
> >
> >
> > OwnerThread Operation ?
>
> Thanks, that helped.
>
> Attached are patches for the toolchain-2.5 branch of OCL. They compile
> clean, and the deployer runs, but I can't test it beyond that. I've also
> attached an example deployment XML file, and a primitive shutdown script to
> demonstrate that side of thins. I know that this approach works in v1, but
> I'm sure there are some issues with it in v2.
>
Requiring that the Application component is periodic is not necessary in
2.x. Why do you require it, even for 1.x ? You're also using usleep()
instead of an rtos_... function, which is bad for portability.
For the rest, the code looks OK and useful. You're violating my recommended
spaces-only coding style though :-)
I also think that this single-function solution is much simpler than
directly using event ports. If event ports are necessary, they can be
used/created in that function.
Peter
Support clean deployer shutdown
On Jun 16, 2012, at 18:10 , Peter Soetens wrote:
> On Wed, Jun 6, 2012 at 9:15 PM, Stephen Roderick <kiwi [dot] net [..] ...> wrote:
> On Jun 6, 2012, at 15:21 , Willy Lambert wrote:
>
> >
> >
> > 2012/6/6 S Roderick <kiwi [dot] net [..] ...>
> > To hopefully save me some time, can someone please point the way in converting the following v1 code, to v2:
> >
> >
> >
> > What are RTT::Commands now?
> >
> >
> > OwnerThread Operation ?
>
> Thanks, that helped.
>
> Attached are patches for the toolchain-2.5 branch of OCL. They compile clean, and the deployer runs, but I can't test it beyond that. I've also attached an example deployment XML file, and a primitive shutdown script to demonstrate that side of thins. I know that this approach works in v1, but I'm sure there are some issues with it in v2.
>
> Requiring that the Application component is periodic is not necessary in 2.x. Why do you require it, even for 1.x ? You're also using usleep() instead of an rtos_... function, which is bad for portability.
Because without being periodic in v1, commands aren't processed and it locks up (I don't recall exactly where/when). I can take that out for v2 if it is now unnecessasry.
Copy on the usleep. Just making sure you had something to push back on ... ;-)
> For the rest, the code looks OK and useful. You're violating my recommended spaces-only coding style though :-)
Yeah, sorry, Emacs kills me (and I _am_ using the Orocos emacs mode).
> I also think that this single-function solution is much simpler than directly using event ports. If event ports are necessary, they can be used/created in that function.
That was part of my design philosophy. This seemed to be the simplest option from which you could generate any necessarily complex solution.
I'll take out the periodic constraint, use the rtos sleep, and try to remove the tabs for you. Will repost the patch then.
S
Support clean deployer shutdown
[Fixes ws, removes periodic, and uses rtos sleep]
sroderick@mp ocl (toolchain-next)$ git request-pull toolchain git [..] ...:~snrkiwi/orocos-toolchain/snrkiwi-ocl.git
The following changes since commit b04db167398553a374a22ac4ac7a5134c971c8ac:
lua: fix link error when readline/curses is not installed. (2012-05-14 22:41:35 +0200)
are available in the git repository at:
git [..] ...:~snrkiwi/orocos-toolchain/snrkiwi-ocl.git toolchain-next
for you to fetch changes up to 4a4a82db556c181ec8a6938f20d8fdeee8c5314c:
bin: Cleanly shutdown deployment (2012-06-23 08:06:41 -0400)
----------------------------------------------------------------
Stephen Roderick (2):
deployment: Support optionally running a deployment shutdown command.
bin: Cleanly shutdown deployment
bin/deployer-corba.cpp | 3 +
bin/deployer.cpp | 2 +
deployment/DeploymentComponent.cpp | 117 ++++++++++++++++++++++++++++++++++++
deployment/DeploymentComponent.hpp | 8 +++
4 files changed, 130 insertions(+), 0 deletions(-)
Support clean deployer shutdown
On Sat, Jun 23, 2012 at 2:10 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
> [Fixes ws, removes periodic, and uses rtos sleep]
>
> sroderick@mp ocl (toolchain-next)$ git request-pull toolchain
> git [..] ...:~snrkiwi/orocos-toolchain/snrkiwi-ocl.git
> The following changes since commit
> b04db167398553a374a22ac4ac7a5134c971c8ac:
>
> lua: fix link error when readline/curses is not installed. (2012-05-14
> 22:41:35 +0200)
>
> are available in the git repository at:
>
> git [..] ...:~snrkiwi/orocos-toolchain/snrkiwi-ocl.git
> toolchain-next
>
> for you to fetch changes up to 4a4a82db556c181ec8a6938f20d8fdeee8c5314c:
>
> bin: Cleanly shutdown deployment (2012-06-23 08:06:41 -0400)
>
> ----------------------------------------------------------------
> Stephen Roderick (2):
> deployment: Support optionally running a deployment shutdown command.
> bin: Cleanly shutdown deployment
>
> bin/deployer-corba.cpp | 3 +
> bin/deployer.cpp | 2 +
> deployment/DeploymentComponent.cpp | 117
> ++++++++++++++++++++++++++++++++++++
> deployment/DeploymentComponent.hpp | 8 +++
> 4 files changed, 130 insertions(+), 0 deletions(-)
>
>
I merged it on toolchain-2.5. The only things left I was pondering about
was if 'Application' should be a property too and if the deployer can have
this shutdown function. I think in any code where a 'peer' can be named,
the component itself should be an acceptable argument as well (by using
'this' or so by convention).
Peter
Support clean deployer shutdown
On Jun 24, 2012, at 17:17 , Peter Soetens wrote:
> On Sat, Jun 23, 2012 at 2:10 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
> [Fixes ws, removes periodic, and uses rtos sleep]
>
> sroderick@mp ocl (toolchain-next)$ git request-pull toolchain git [..] ...:~snrkiwi/orocos-toolchain/snrkiwi-ocl.git
> The following changes since commit b04db167398553a374a22ac4ac7a5134c971c8ac:
>
> lua: fix link error when readline/curses is not installed. (2012-05-14 22:41:35 +0200)
>
> are available in the git repository at:
>
> git [..] ...:~snrkiwi/orocos-toolchain/snrkiwi-ocl.git toolchain-next
>
> for you to fetch changes up to 4a4a82db556c181ec8a6938f20d8fdeee8c5314c:
>
> bin: Cleanly shutdown deployment (2012-06-23 08:06:41 -0400)
>
> ----------------------------------------------------------------
> Stephen Roderick (2):
> deployment: Support optionally running a deployment shutdown command.
> bin: Cleanly shutdown deployment
>
> bin/deployer-corba.cpp | 3 +
> bin/deployer.cpp | 2 +
> deployment/DeploymentComponent.cpp | 117 ++++++++++++++++++++++++++++++++++++
> deployment/DeploymentComponent.hpp | 8 +++
> 4 files changed, 130 insertions(+), 0 deletions(-)
>
>
> I merged it on toolchain-2.5. The only things left I was pondering about was if 'Application' should be a property too and if the deployer can have this shutdown function. I think in any code where a 'peer' can be named, the component itself should be an acceptable argument as well (by using 'this' or so by convention).
>
> Peter
I considered this too, but as we didn't need it for our situation I left it out. It's a good idea.
In v1 I couldn't make the deployer run the shutdown function. It gave me grief, but I don't recall exactly what the problem was.
S