Re: [Chicken-users] External representation for continuations

[felix]

Thomas Chust wrote:

> Information like that already exists in every file compiled with 
> debugging information, so perhaps one would be able to access it without 
> too much trouble. The bigger problem will probably be the serialization 
> of code that is dynamically loaded or generated at runtime, because it 
> also requires transmission of the code itself, not only of an identifier.

I'm not sure whether using debugging info is the best solution:

a) `strip' will render an executable without any serialization info
b) it would be dependent on the deug-info format
c) it wouldn't be very portable (say, to the MSVC toolchain)

Code generated at runtime doesn't happen yet (besided evaluated code,
and here the C procedures are already there and should be just as
serializable as compiled closures). Dynamic wouldn't be problematic
either, provided we require the deserializing process has loaded the
same modules.

> > But serializing continuations is a tricky business: ports and foreign-
> > pointers have to handled specially and one has to make sure that a cont.
> > does not pull in the whole global environment.
>
>
> That's certainly a point. I think, stuff like ports and foreign pointers 
> should simply become closed / invalid during serialization, unless one 
> wants to implement a sophisticated callback system allowing access to 
> those data objects on the original host. But if one also allows remote 
> acces to data objects, garbage collection becomes a nightmare.

Indeed.

> The problem with the environment was solved in the original Kali Scheme 
> implementation (which was implemented on a stack based Scheme) by only 
> transmitting the top few stackframes with a continuation and loading 
> more frames over the network if they were actually needed. This is 
> reasonable for example when migrating tasks across a network. I have no 
> idea how to port this concept to CHICKEN, though.

Neither do I. But the idea is clever. The SISC people have serializable
continuations, I should get into contact with Scott Miller about this and
ask how they handle this particular issue.

> > [...]
>
>
> Well, if I have far too much time some day, I will try to come up with a 
> solution ;)

Please do! :-)


cheers,
felix