RE: Re: stackless implementation (was Re: New stacklessproposal)

> From: Christian Tismer

> > If "stack pooled" can do everything and is fasted and smallest why 
> > offer anything else?  Is there no disadvantage at all?
> 
> There is the disadvantage that it doesn't exist, yet. I have 
> to actually implement it, to see if the speed advantage is 
> relevant to justify allocation of extra stacks.

What is the "cost" of extra stacks?  Is it memory or speed?  As long as
it is less memory than OS and faster than OS then it is justified.

> And a clear disadvantage is that you have to do assembly or 
> alike. So, for Stackless I'm planning to make this a 
> configurable option, since on some platforms, it may *always* 
> be slower, if they have tons of registers to discard.

If it is slower that the pure interpreter on some platforms but supports
C extensions, I may still decide to go with only that solution.  Having
a combination solution where one choice doesn't support C extensions is
very non-orthogonal and messy, especially if it is only for the benefit
of a small part of the user base.

> > Can I trust you enough to say that we will only offer one type of 
> > super-thread that does it all. :-)
> 
> I'm pretty sure, but early marketing is never a good idea.

All of Prothon is one big promise. :-)  Anyway, if it doesn't work we
just drop back to plan B.

> > Can I add pre-emption and sleep() without harming the 
> normal operation 
> > of your threads?
> 
> Yes. It can be that I need to restrict these extra stacks to 
> a single tasklet, each, to keep the speed advantage.

If there is C stuff on the stacks, then don't they have to be
arbitrarily big because we cannot predict how big they need to be?  Or
do you still have one big OS stack that they initialize on and then you
copy only what the C function uses over to the multiple stacks?

> Will try to produce a prototype and do some timings.

In early August we will be ready to try your code in Prothon no matter
how ready it is.