Persisiting the call stack / heap etc.

  • Thread starter Thread starter Anders K. Jacobsen [DK]
  • Start date Start date
A

Anders K. Jacobsen [DK]

Hey.

Is it possible somehow to persist the call stack, heap, program
data...everything. Then at a later time load it again and continue work. The
idea is actually to send it all over network in a pervasive research
project, so that one program can be used on one computer and "instantly"
continue on another.. Im not looking for a solution, rather som keywords, no
goes and so forth.

Im planning to use .net 2.0 if the projekt is remotly possible.

Looking very much forward to hear from you.

Anders Jacobsen
 
Hey.

Is it possible somehow to persist the call stack, heap, program
data...everything. Then at a later time load it again and
continue work. The idea is actually to send it all over network
in a pervasive research project, so that one program can be used
on one computer and "instantly" continue on another.. Im not
looking for a solution, rather som keywords, no goes and so
forth.

Im planning to use .net 2.0 if the projekt is remotly possible.
Click to expand...


Anders,

This may be possible by using the .Net debugging API (ICorDebug).

Mike Stall would know for sure. There's a contact link on his blog:

http://blogs.msdn.com/jmstall/default.aspx
 
Be pretty involved...it would not only have to persist the entire contents
of memory of the process, for both managed and unmanaged code, but would
also have to "know" what all the open handles to unmanaged resources meant
and somehow recreate them on the other computer. e.g. open files, network
connections, database connections, connections to device drivers, etc. would
all need to be recreated. It would be a lot easier if you could define away
some of the scope, such as persisting only a pure managed application (no
interop), and one that is at a known "safe" point where it has no open
handles to unmanaged resources, all threads are at a known state, etc.
Offhand I'd say it's not worth the effort...serialization of objects with a
global task scheduler may be a better way to go.
 
Thanks for your input. The applications would be entirely managed.
Applications would further work disconnected on data wich also simplifies
things abit. Your suggestion about using serialization is very much a
possibility. I could indeed use eg. a memento patten to store state about
the application. But there are two problems herre:

1. It would require that applicationo was written from the first source line
with this in mind. I would be very interesting to have the abilty to take
any given application (with some constraints of course) and serilalize their
state. Or atleast only do limited modifications to the source code.

2. It has been done before an is therefore not that interesting as research
project. Im interested in finding out if the .net framework (2.0) provides
som mechanisms which supports this in some degree.

But of course Im aware of the massive complications but thats OK. It does
not have to actually work :) though it would be nice to know that the
project is impossible.

Anders
 
1. It would require that applicationo was written from the first source
line with this in mind. I would be very interesting to have the abilty to
take any given application (with some constraints of course) and
serilalize their state. Or atleast only do limited modifications to the
source code.
Click to expand...

The ability to take any given app and do this gets right back into all the
complexity. I think you would need to design this functionality into your
app from the ground app, and even there it would take a lot of effort.
Another approach is to use a master scheduler to break the work load into
chunks and parcel them out to different machines. If one machine failed to
complete the task the chunk could be rescheduled somewhere else.
2. It has been done before an is therefore not that interesting as
research project. Im interested in finding out if the .net framework (2.0)
provides som mechanisms which supports this in some degree.
Click to expand...

Not that I know of.
But of course Im aware of the massive complications but thats OK. It does
not have to actually work :) though it would be nice to know that the
project is impossible.
Click to expand...

Nothing is truly impossible...it's all a matter of hardware, software, and
how much time, money, and resources you are willing to dedicate to it. Now,
whether or not it is worth doing....
 
Back
Top