Re: stackless implementation (was Re: New stacklessproposal)

"Mark Hahn" <[email protected]>
Newsgroups gmane.comp.lang.prothon.user
Message-ID <[email protected]>
Christian Tismer wrote:

> You just discovered Stackless 2.0, which was hardware
> switching, only.
>
> I will show you how I do it.

Some random thoughts if you don't mind....

What you have done is written OS threads that are harder to implement than
real OS threads.  You have all the problems of saving and restoring the
registers as usual plus the extra problems of reusing the same stack with
the copying.  You will probably be slower than an OS switch but you will
have the advantage of using less memory.

So we have three types of threads (mixed is stackless 2.0):

Pure OS:  High memory.  Medium speed switch.  C extensions allowed.  No
pickling.

Mixed:  Low memory.  Lower speed switch.  C extensions allowed.  No
Pickling.

Pure interpreter: Low memory.  High speed switch.  No C extensions.
Pickling OK.

I was originally thinking we would only have the pure OS and the pure
interpreter.  Now we have the new more complex mixed type.  There are no new
language features required for the mixed.  The mixed just removes some
severe restrictions.

Should we give the programmer some control over which of the three they get
other than the obvious that they cannot use a c extension with the pure
interpreter?

It is a shame this is getting so complicated.  It would be nice to make it
automatic so we could hide the complexity from the programmer.  I wonder if
any algorithm could be smart enough to always make the right choice for
them?

The only time the programmer is really screwed is if they try to use c
extensions and pickling.  Every other combination is supported in the
matrix.

Why not just have the algorithm choose to always use the fastest pure
interpreter unless they use a c extension and then drop back to the mixed.
Then if they use too many threads drop back to OS threads.  We could let
them override the defaults of course.  This way we would only have one type
of thread instead of two and let the thread types be hidden from them in
normal default usage.

In your last message you were talking of having multiple real C stacks.  I
assume you were not going to let the OS do the C stack switching?  You are
starting to replace OS functions.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.