Stackless Platform Independence?

[Frederic Giacometti]

"Courageous" <jkraska at san.rr.com> wrote in message
news:987e7uoo5v87fsjruq0ug6bff0vha5ear0 at 4ax.com...
>
> >I am personally still surprised that stackless has not be considered more
> >seriously in the python-dev group, especially in regard to the threading
> >problems and limitations of the current python versions.
>
> Well, keep in mind that stackless threads aren't OS threads at all.

Yes, this is very much the point, and Python os thread furthermore require
global interpreter lock operations. There's no free lunch there; and some
significant limitations too.
In addition to all the benefits that Christian has described so far,
stackless python would make it possible to have a different OS
multi-threading implementation for calling external C/C++ libraries; one
that does not require interpreter lock operations.
However, stackless is a pre-requisite for such things.


> The way I have it, Stackless _was_ considered by Guido and team,
> it was just regarded as both too dirivative and too complicated to
> make part of core Python. Look out in the real world and try to
> find out how many languages have continuation support in them.
> Not very many.

>From what I have perceived, there has been confusion in the debate, between
stackless and continuations.
Most of the remarks I've been aware of are against pure continuations
(basically, arbitrary use of continuations, like C goto, would just break
program flow structure, with all the consequences one can imagine).
Complexity problems are also regarding continuations.

I'm not too familiar with other scripting language implementations, but Java
and Perl, at least, I think, are stackless!!

The concept of stackless is a lot simpler, and its implementation has no
particular technical obstacles; especially since Christian made the proof of
concept.

Stackless just means that function calls executed by the bytecode are
executed by a C function that returns immediately; thus disconnecting the C
call stack from the virtual machine call stack.
In current python, they are interleaved one-on-one; making it impossible to
switch context within the VM unnless you do Christian's last 'non-portable'
assembly language manipulation.

Christian's first implementation was at the C source level, and wasn't that
complicated to integrate; its implementation had to be reengineered, but
there was no out-of-this-world wizardry there.

Provided a proper source organization, stackless implementation would not
add much complexity to the python VM (one additional data structure,
basically). However, it's true that, because of source management issues
(Christian did not create additional files), Christian implementation could
not be integrated as such.

> I personally make great use of continuations in a simulator core
> I wrote. While I grok them, I have the feeling that an average
> programmer following in my footsteps would have to read my
> comments very very carefully before he could come to understand
> how a certain central function call in my simulator actually
> returns millions of times.

Once a stackless implementation of the Python VM is provided, continuations
can always be proposed as optional module, external to the python standard
distribution.
Continuations is one item of what stackless would enable.
Python microthreads would certainly be the most significant outcome, but
there will be others too.
The debate on continuations should not be mixed with stackless; and very
much valid arguments against continuations should not be used to argue
against a stackless Python VM implementation.

Frederic Giacometti