guile-devel
[Top][All Lists]
Advanced

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

Re: Threads and asyncs


From: Lynn Winebarger
Subject: Re: Threads and asyncs
Date: Wed, 4 Sep 2002 18:46:16 -0500

On Monday 02 September 2002 20:48, Lynn Winebarger wrote:
>       As for the rest, I think we should make C functions
> declare themselves as primitives that never call Scheme,
> and "other", that might call eval.  The first could use some
> fixed "scratch" stack space, the others should get a freshly
> allocated stack (whose size they declare through snarfage
> or somesuch).  The interpreter could then analyze the
> scheme code to find regions "between" call/cc's that could
> use some fixed stack.  Call/cc's allocate a fresh Scheme
> stack for the "next" block of code that gets executed.

    I believe I can be clearer on this now.  
    Let's say we're doing some computation on stack A with
frames A1 - A50, recalling that primitives (whether foreign
or internal) have their own "scratch" stack, and non-primitive
foreign functions get a freshly allocated stack; so that A really
contains only frames generated by eval.  Now, let's say we
see a call/cc for the first time at A50, so we allocate another
stack and set its continuation to the top of this one.  Now,
after returning from that call (if/when that happens) any
subsequent stack using calls get their own stack space, with
a continuation into A wherever it left from.  For example,
let's say I returned, and then descended the stack to frame
A40, then called myota (defined in Scheme).  Then a new stack
C (since B was allocated for the first call/cc) gets allocated
with its continuation pointer to A40 (and maybe to A's bottom
to make the GC's job easier).  
  This amounts to lazy allocation of continuations, whereas a 
straightforward implementation where each stack frame is 
freshly allocated will result in lots of garbage, this should result 
in only as much continuation garbage as absolutely necessary.
Call/cc should be reasonably fast,  and current C programs
can be grandfathered in by assuming non-primitivity, and
only a minimal amount of declarative work for those who
want GUILE to know which of their functions are primitives.
Of course, there should also be some way to return unused
space off the top of the stack to the GC.  The garbage collector
could be made to recognize when the top part of the stack
is no longer referenced an can be reused.
     Did that make sense?  Anyone see a hole in it?

Lynn




reply via email to

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