[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] External representation for continuations

From: Thomas Chust
Subject: Re: [Chicken-users] External representation for continuations
Date: Wed, 01 Sep 2004 13:39:57 +0200
User-agent: Mozilla Thunderbird 0.5 (X11/20040306)

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 ;)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]