Strange Process Question

OK, I can fork off a new session, then suspend the session. Can I now  
save the suspended session to disk and open it in another image (or  
in another application in the same image)?

-Rich-

On Wed, Aug 16, 2006 at 03:57:02PM -1000, Rich Warren wrote:
> OK, I can fork off a new session, then suspend the session. Can I now  
> save the suspended session to disk and open it in another image (or  
> in another application in the same image)?

What do you mean by "fork off a new session"? If you are referring to
#forkSqueak, then see the code in SmalltalkImage>>saveAs. You can do
something similar to this in the child Squeak to save it to an image
and changes file that you can open later on.

Dave

On Aug 17, 2006, at 1:02 AM, David T. Lewis wrote:

Ah, sorry. Fingers confused, typing error.

That should have read "fork off a new process".


e.g.

myProc := [this is my block that takes, oh lets say 3 hours to  
complete] fork.

Can I suspend myProc and save it to disk (seperately from quitting  
and saving the whole image)? Can I load it into different objects and  
resume it? Can I sneaker net it to a different machine and load it in  
a completely different copy of Squeak? Or will bad things happen?

As a quick experiment, I tried to "save and quit" squeak while I had  
a suspended process. Squeak locked up completely. I only tried it  
once, however. So that may have just been a bit of random misfortune.  
But it's the only time squeak has ever locked up on me.

I'm not sure where I'd ever use this. The SmalltalkImage stuff you  
mention is probably more generally useful. But I'm still curious.

-Rich-

On Aug 17, 2006, at 7:35 AM, Rich Warren wrote:

> Can I suspend myProc and save it to disk (seperately from quitting  
> and saving the whole image)? Can I load it into different objects  
> and resume it? Can I sneaker net it to a different machine and load  
> it in a completely different copy of Squeak? Or will bad things  
> happen?

In theory, yes, you can. A Process is just objects, and if you  
reconstruct those objects in another Squeak image exactly as they are  
here, it should resume just fine. In practice, however, it's  
difficult to get it to work.

One of the issues is getting all the objects you need. A Process is  
basically a linked list of activation contexts (stack frames). You  
can walk that list and do whatever you like with the contexts - this  
is how Seaside implements continuations, for example. So lets say  
you're serializing them to disk. Each context contains references to  
its local variables, so you've got to serialize those as well. And of  
couse, those objects have their own internal states and references to  
other objects. Activation contexts also refer to the CompiledMethods  
that are being executed, so you've got to make sure they get  
serialized, along with all their literal objects. Often those  
literals include classes, with all *their* compiled methods... once  
all those objects are included in your serialization, you're likely  
to have the entire image.

You might take a few shortcuts, like just including stubs that stand  
in for CompiledMethods, so you can hook them up to their equivalent  
versions when you rematerialize the process in the new image. In that  
case, though, there's the risk that the new image won't be quite like  
the old one, and there will be a different version of the method  
present, or it might be missing all together. In that case the  
process wouldn't be able to resume properly.

So again, in theory possible, in practice difficult. Gets easier if  
you can narrow the scope of what you want to do - Projects are a good  
example of this.

> As a quick experiment, I tried to "save and quit" squeak while I  
> had a suspended process. Squeak locked up completely. I only tried  
> it once, however. So that may have just been a bit of random  
> misfortune. But it's the only time squeak has ever locked up on me.

Beats me. There should be no problem saving Squeak with a suspended  
process, though.

Colin

     Rich writes:

> Can I suspend myProc and save it to disk (seperately from quitting and
> saving the whole image)? Can I load it into different objects and
> resume it? Can I sneaker net it to a different machine and load it in
> a completely different copy of Squeak? Or will bad things happen?

     Okay, you all saw it coming, but I'll say it anyway. :)

     This is straightforward in Spoon, although a process is transferred
directly from one running system to another (not to a distinct storage
artifact first). The providing system can ensure that all the necessary
objects Colin described are present in the target system, while actually
transferring only those objects which are missing from the target system.

     Both systems have a clear notion of exactly which versions of all
classes and methods are present. If the target system is extremely
different from the providing system, then it's possible that a
tremendous number of objects may need to be transferred. But I expect
the typical case would be that the target system is a simple copy of the
providing system before the process was started, so in most cases
relatively few objects would need to be transferred.

     It's worth noting again that Spoon transfers all method literals
perfectly, including shared ("pool") variables. This is something that
is notoriously error-prone when the transfer medium is source code or
static serialization (e.g., Squeak's ImageSegments or ReferenceStreams,
VisualWorks' BOSS). And this is possible because the target system gets
a say in what to transfer and how to transfer it, right while the
transfer is taking place; the providing system doesn't have to decide
all that by itself.

     Finally, one can distribute work amongst multiple systems at a
finer grain than processes (namely, at the level of individual
message-send). Cheap message-sends could remain local, while expensive
ones happen remotely (e.g., on remote hardware sufficiently fast to
amortize the network overhead, which would certainly be the case if the
message-send runtime is on the order of three hours :). Everything is
still happening in the same process as far as the local system is
concerned, and you can still debug everything live from one place.


-C

--
Craig Latta
http://netjam.org/resume