guile-devel
[Top][All Lists]
Advanced

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

Re: Threads and asyncs


From: Tom Lord
Subject: Re: Threads and asyncs
Date: Mon, 2 Sep 2002 16:24:35 -0700 (PDT)

   From: Rob Browning <address@hidden>

   > If I understand correctly, one of the reasons guile used the "one (C)
   > stack with copying" approach was so that call/cc could work properly
   > with a stack that included intermixed C and scheme function calls
   > without too much extra magic.  If that's a correct assesment, then how
   > do you deal with that problem in a stackless approach?


Well, blush....

I think I initially overvalued that feature.   I (nowadays) don't
think it should be central to _any_ implementation.

Instead, i'd make an implementation that is good as just a pure scheme
implementation, then add in that seductive integration with that C
stack via a foreign-function interface.  I think a good pure scheme is
not at all likely to use the C stack that way, especially for
procedures of central importance like `apply' and `eval'.

Most primitives, especially the core ones, would not rely on using the
C stack in the manner of SCM.

But since Guile is an extension language, one should _be able to_
write primitives that way (i.e. C-stack friendly), perhaps with a
modest performance trade-off, when necessary.  That would let people
add Guile to programs with minimal disruption.

In fact, the C-stack-friendly API could be made largely implementation
independent.

If Guile never budges on the stack issue, I would still be inclined to
see it as an implementation optimized for cases when the C stack is
used heavily.



   > It was also my impression that the call/cc issue, along with an
   > aversion to having to explicitly deal with GC on the C side (which as
   > you've pointed out before might be dealt with via preprocessing,
   > etc.), were the two main things that would make switching to a
   > stackless approach somewhat controversial or difficult.  Are those the
   > only two big issues, or are there others?

You've caught me talking from memory.   We'd need to sit down with a
wiki or whiteboard and map it out together.   I won't pretend to be
able to list all the issues off the top of my head.   I won't pretend
to have finished my own personal map of the various design spaces :-)

Do you have a good library of Scheme implementation papers?  Maybe
there should be a collaborative bibliography to bring together a bunch
of the good ideas floating around out there.

-t






reply via email to

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