ANN: Stackless Python 0.2

[Corran Webster]

In article <377757D5.25A2AFF6 at appliedbiometrics.com>,
Christian Tismer  <tismer at appliedbiometrics.com> wrote:
>
>Corran Webster wrote:
>> 
>> I managed to get this to build eventually (thanks to the hints from Michael
>> Hudson).  Looking at it, I wonder whether there's the potential here for
>> more than coroutines and to write an implementation of threading within
>> Python.  Each thread would presumably need its own Python stack, and a
>> queueing and locking system would need to be added somehow, but because
>> the Python and C stacks are no longer intertangled, switching between
>> threads should be easy (as opposed to impossible <wink>).
>
>Please be a little patient. :-)

Apologies if this read as a request for someone else, such as yourself,
to impliment this.  This was at the idle speculation stage for me, and
I hadn't seen any previous discussion of it, so I thought it worth asking
about.  Apparently it has been talked about, which is cool.

>> This wouldn't be quite as flexible as the current implimentations of
>> threads at the C level - C extensions would be called in a single block
>> with no way to swap threads until they return.  On the other hand, this
>> would allow every platform to have some sort of threading available,
>> which would be a boon.
>
>Not really. C extensions can be written in a stackless
>manner. Whenever they need to call into the interpreter,
>they can do it in a conformant manner. They do so by just
>using their own frame with their own executor.
>You need to change your thinking here: There is no return
>in that sense any longer. We just have frames in some chains,
>and all local state is kept in frames.

Okay - from your reply and Tim Peters', it seems as though my understanding
of the way the Python stack works was somewhat wrong.

>> Unfortunately I'm not familiar enough with threads to go out there and
>> implement it right away, but I thought I'd at least raise it as a
>> possibility and see what people think and what the pros and cons are.
>
>It will be available soon, and it will be nothing more than
>a Python module which tames continuations to behave as threads.

Looking forward to see what you come up with.

Corran