Re: Threads and asyncs

[Lynn Winebarger]

On Monday 02 September 2002 20:27, Rob Browning wrote:
> Tom Lord <address@hidden> writes:
> 
> > ObPolitics: If you think this is merely a friendly design space
> > disagreement, that will work itself out on the merits of which idea
> > works out better in practice, think again.
> 
> Believe it or not, I was *actually* thinking "I hope no one brings
> this up so we can continue with a conversation that *appears* to be
> headed in a productive direction."

    I agree, it was headed in a good direction (actually right towards
the subject of the "Stack SIze?" thread on guile-user).
     What is the upper limit on the trouble Guile users could be made
to deal with vis-a-vis garbage collection, in particular, precise
generational,copying,compacting garbage collection?  They apparently
have to go to some trouble now to make sure the compiler doesn't
optimize SCM's off the stack.  Would it be too much to have them
explicitly declare the lifetimes of these SCMs (alternatively, to insure
they are accessible from some known root)?  Or to make them
not hide SCM's in other values in the un-preprocessed source
(so we could write a pass to analyze types for the GC to use)?
     Yeah, I know, it's all blue sky.
     As long as we're at it, I'd like the C continuation semantics to 
be that you can't return from a C function twice, but otherwise
you can jump back and forth between Scheme code even
if you returned through the C function once.  There's really
no reason to pretend C functions have anything like a real
continuation, so we shouldn't have to go to special lengths
to support them (ok, keep around the old behaviour for those
who really,really want it applied to specific functions that are
written specifically to be valid: i.e. they guarantee no resources
in use (other than the ones on the stack, which are maintained
by the copying) are explicitly freed by their return.
      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.
    Is that enough to get us back on track?


ObGripe:  Pick one mailing list or the other.  

Lynn