|
From: | Thomas Chust |
Subject: | Re: [Chicken-users] External representation for continuations |
Date: | Wed, 01 Sep 2004 23:59:26 +0200 |
User-agent: | Mozilla Thunderbird 0.5 (X11/20040306) |
felix wrote:
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.
Sorry for the stupid question, but what does CHICKEN make of an (eval (read)) in compiled code? I don't quite understand what you mean by "the C procedures are already there".
[...]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.
Hmm, I just tried it out with the last SISC release -- serializing a continuation works all right, but deserializing it crashes the interpreter :-( De-/Serializing procedures and other stuff works fine, though.
I'd actually be interested in the code of the original Kali Scheme implementation (which was based on Scheme 48). But it seems to be no longer available for download...
[...]
cu, Thomas
[Prev in Thread] | Current Thread | [Next in Thread] |