Continuations and threads (was Re: Iterators & generators)

[Aahz Maruch]

In article <38ACA6EE.90D582DF at prescod.net>,
Paul Prescod  <paul at prescod.net> wrote:
>Aahz Maruch wrote:
>> 
>> Assuming that I've understood everything you've said about
>> continuations, I think I also understand what Tim meant about modeling
>> threads with continuations and vice-versa.  Seems to me that one could
>> easily implement continuations with a process that forks off and blocks
>> waiting for one of two signals: resume or die.  (When a process forks,
>> both processes have almost exactly the same state, right?)
>
>Okay, but how is implementing threading via fork() using continuations?
>The underlying OS task switcher is doing all of the work, not the
>language's continuation feature.

No, no, I meant that one could implement continuations using fork() and
IPC.  It should therefore be possible to implement continuations using
threads.  And I think that's all the Timbot meant.

>>  [code deleted]
>> Am I right?
>
>Well your version had some improvements but I think that they make more
>clear the fact that the while loop is not useful. The continuations will
>bounce back and forth forever by themselves. In this case they are very
>much like "goto" in basic which probably explains why Common Lisp people
>hate them.

Uh-huh!  I have to admit that I almost ripped out the while loop because
it looked like it wasn't necessary, but it occurred to me that the
semantic of a reference to an object returned by currentContinuation()
could include advancing the PC in the current continuation frame.  Which
means that the initial call to producer really ought to look like:

    continuation producer()
--
                      --- Aahz (Copyright 2000 by aahz at netcom.com)

Androgynous poly kinky vanilla queer het    <*>     http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6

Our society has become so fractured that the pendulum is swinging
several different directions at the same time