Re: De-facto standard CL implementation of continuations?

On Sat, 13 Aug 2005 23:20:49 +0000, Ray Dillinger wrote:

> It's not required by the standard, but in many of the
> better scheme implementations, you can use read and
> write to serialize/deserialize continuations, both
> to/from files and strings.
>
> I haven't looked at exactly how it works though

Neither have I, but that won't stop me from speculating ;-)


> now that I think about it I'm curious how they avoid garbage
> collecting the invocation frames of the procedure calls
> involved if they don't maintain a reference to the
> continuation.

This, I believe, is orthogonal to serialization.


> Or maybe they have to serialize the
> entire "stack" with a continuation read it back in,
> and replace any collected frames. But then mutations
> in scoped variables don't get preserved if the frame
> is mutated and then reaped before the continuation is
> read back, so how.... ?

There are a few issues going on here. I'm guessing here, but I would say
that compilers that do serialize are just giving you something for free.

When handling your normal everyday continuations there are generally two
methods: i) copy stack on capture, ii) allocate *all* frames in heap
avoiding the stack entirely. When you already have written the code to
copy the stack, it's trivial to write it out to a file. And there is no GC
issue as the stack is self-contained (i.e. all local variables are
contained in the stack and references are stack offsets). Think of it as
writing a C struct to a file and reading it back in (modulo alignment
issues). The fields contain the correct data, so far as correct means what
you serialized. If you mutate a field, exit the program, load the
program and read the serialized struct... you only get the version of the
field (variable) you saved.

All that said, you might run into a problem if you do something like...

(set! *global-var* (call/cc (lambda (k) (save-cont-to-file k)))

Then later reload the system but forget to load the right modules or
define all the top-level variables. Nasal demons, etc. etc.

The stack method is seen as the more difficult method to implement, so
it would be no surprise if the better implementations used it. And while
we're at it... the theory goes, those that use call/cc should pay the
higher price (stack copy method) rather than penalize all procedure calls
(heap). But the "heap is slow" theory has been disputed, and it all
really depends on so many more details that, if you didn't know your
requirements, you could flip a coin and it wouldn't make a bit of
difference which method to pick.


Tim


.

Relevant Pages

  • Re: Garbage collection problems
    ... a C-implementation allocating all the call frames on a heap. ... grab a chunk of memory for this and attach to ... you are implementig the stack in software. ... function (such as the current continuation, part of the lexical scope, ...). ...
    (comp.lang.c)
  • Re: De-facto standard CL implementation of continuations?
    ... can you serialize a Scheme continuation? ... Or maybe they have to serialize the entire "stack" with a continuation read it back in, and replace any collected frames. ...
    (comp.lang.lisp)
  • Re: Network Stack Locking
    ... :>:of continuations during IPC to avoid a full context switch. ... Even a minimal stack is ... :> continuation mechanism increases as system load increases rather ...
    (freebsd-arch)
  • Re: CP/M-86 1.1: HLT requested
    ... On 2006-02-13 Steve Dubrovich said: ... >> serialize: ... > The other issue is the small stack size. ... 'CVV' hard disk driver -- which also increases the available stack ...
    (comp.os.cpm)
  • Playing the bubble against an aggressive big stack
    ... I continued to grow my stack, ... The blinds were 100/200. ... called then went allin against my continuation bet on the flop. ...
    (rec.gambling.poker)