Re: [Chicken-users] External representation for continuations

[Thomas Chust]

Felix Winkelmann wrote:
> [...]
>
> Basically everything is possible... ;-)
>
> I pondered about this quite a bit. Basic serialization of data is not
> a big problem, but code is somewhat tricky. A closure (or continuation)
> contains a code-pointer to some C routine. To properly serialize a closure,
> the code-pointer would have to be converted into some unique id, which,
> when deserialized back into a running process must be converted into
> a code-pointer again (we can't just write the code-pointer directly:
> in a process that deserializes a closure, the code-addresses may be at
> completely different locations, or might even not be available, for
> example if a library is not linked, which was used and referenced in
> a serialized continuation/closure).
>
> One possible solution would be to generate a function-table for each
> compiled file that maps code-pointers to unique identifiers). On 
> serialization
> a code-pointer would be looked up in that table, the id written and on
> deserialization the id is searched in all loaded/linked units/modules
> and converted back into a code-pointer.

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.

> 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.

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.

> [...]

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

cu,
Thomas