Boost logo

Boost Users :

Subject: Re: [Boost-users] Transfering the process state to another process
From: Nigel Rantor (wiggly_at_[hidden])
Date: 2009-11-07 22:07:07


Lloyd wrote:
>
> Hi,
> We want to have a program which cannot be terminated by the user (even
> admin). I think the only way to do this is to write a watchdog process.
> So there will be a master and a slave process, the master will be the
> active process, and the slave keep on watching the master. I case if the
> master is terminated, the slave become master and initiates a new slave
> process. But we need to transfer (or share) the process state of "old
> master" with the "new master" (So that the new master can continue form
> where the old master has stopped). Is this possible with shared memory?
>
> Or is there is a better way?

I imagine that any decent admin would tell you, politely:

"Please don't try and create a process I cannot kill when it goes
haywire, if you try I won't be running it in the first place."

Fundamentally though you can try and create a process like that but
you'll waste a lot of energy on something that you probably don't want
to do anyway.

Having said all that, ensuring that a process maintains some state so
that processing can be continued by a newly created process in case it
dies for some reason is a completely different matter.

How you store the state will depend on what kind of state we're talking
about, there's too many possiblities to try and guess at what you
require. Details please.

When it comes to gracefully restarting a process you will need to think
about a few things.

How will the watchdog tell when the current process is defunct?

How quickly after becoming defunct must the process be restarted?

What level of data "loss" is acceptable, and if we're talking about a
server with clients, what happens to the work they've done so far?

Again, this is a really huge landscape, and without knowing your
requirements any advice is probably going to be of limited value.

Regards,

   n


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net