stackless implementation (was Re: New stackless proposal)

Christian Tismer wrote:

> [consumer/producer, who is on the stack]
>
>> My proposal has the implementation that explains the answer to your
>> questions.  The first next() call creates and calls the generator
>> thread and then calls yield to get the first value.  Niether thread
>> will have to reconstruct any stack state.  Both threads will have
>> their own stacks existing the whole time they run.  The generator
>> stack will run until it terminates and then it's stack will be
>> destroyed.  The calling stack will be the normal stack that exists
>> before and after the gen is used.
>
> Ah, oh! I did not expect that you are doing assembly tricks.

Assembly tricks?  We have a big communication problem here.  My stacks are
just  linked lists of  Prothon frames.  There is no C stack involved.  Why
would there be any assembly code involved?

OH!  I keep forgetting the restriction that a Thread being used as a
co-routine can't call a C extension.  I need to put this in the proposal.
There must be only one Thread that is the main Thread that can have the C
stack intermixed and never terminates.  Damn, this is getting messy.

>> My proposal DOES have two stacks and a real switch.  Each thread has
>> its own stack and the threadMgr is a real switch.  What can I do to
>> explain my implementation better?
>
> I completely understood.
> Fine, I feared Stackless had a real competitor,
> but this is not the case. :-))

How does your stackless implement the multiple tasklets?  Does it allow C
extensions in a tasklet?

> I was talking of a cooperative interpreter implementation.

I have only been talking of cooperative interpreter implementation also.

> But if I see it reight, you dpn't make any use of it?
> Switching stacks is really easy, but won't let you get
> below thread sizes of Windows Fibers (64k I think).

We have gotten into mis-communication land here.