[Gcl-devel] Re: more si::save-system harrassment

[Camm Maguire]

Greetings!

Robert Boyer <address@hidden> writes:

> One important reason that si::save-system ought to (at least have the option)
> to write a file that can be restarted right where the si::save-system was
> executing (as opposed to starting over at the top level) is as an important
> basis for parallelism.  Consider a p-let, say, that is implemented by saving
> the whole image and then shipping the resulting file to an entirely different
> machine for execution.  By the way, this would also include enhancing
> si::save-system so that it does not simply exit GCL after making the save
> image, but continues executing.  Of course, there has to be, as with
> si::fork, some subtle mechanism whereby the continuing image can be
> differentiated from the restarted image.

I agree that save-system should have the functionality you seek.  I
would also like to be able to open a shared lib in a session, refer to
it in a few compiled modules, save, and then have the new shared lib
automatically loaded on reexec.  I'll try to put both on the queue.

Just wanted to mention here that there is a far simpler way to do the
parallelism you mention above -- MOSIX.  This is a kernel patch to
Linux which allows processes that communicate via a socket to migrate
across nodes of a cluster determined by some load balancing algorithm
in the kernel.  All we would have to do to take advantage of this (to
my knowledge) is to replace the call to pipe in fork with socketpair.
It would be nice to find a test system on which to check this out.
Socket i/o should be somewhat slower than half duplex pipes, however,
so I don't know if this should be the default.

Take care,




> 
> Bob
> 
> 
> 
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah