[pypy-dev] Confusion with meaning of "Stackless"

Michael Hudson mwh at python.net
Thu Dec 14 10:11:36 CET 2006

Armin Rigo <arigo at tunes.org> writes:

> Hi Lenard,
> On Wed, Dec 13, 2006 at 03:50:21PM -0800, Lenard Lindstrom wrote:
>> Tasklets are nice, but I just wish to update my understanding of 
>> "Stackless". Does the old motto "A Python Implementation That Does 
>> Not Use The C Stack" [1] still apply? Is it relevant to PyPy?
> Yes and no.  A bit confusingly, the usage of the term has evolved, along
> with the Stackless Python project itself.  Now, "a Stackless feature"
> means a feature that cannot be implemented without some form of explicit
> stack control, either by being very careful about the C code (e.g.
> avoiding recursive calls) or by saving and restoring pieces of the C
> stack by a brute force 'memcpy' approach.  In PyPy, we use a variant of
> the former approach: a "stackless build" of pypy-c is a compiled version
> of some C code that was generated with careful systematic tweaks.
> The motto of a Stackless PyPy is probably: "A Python implementation that
> uses the C Stack as a cache".  Indeed, the C code supports saving its
> own stack of frames away into the heap, and restoring it from there,
> frame by frame.  So the C stack is really just a cache for the heap.  If
> the cache is full (stack overflow), we save some more frames into the
> heap to free some cache space.  If a context switch occurs (coroutine
> switch) the cache is invalidated (entierely flushed to the heap) and the
> new context's frames are copied from the heap to the cache as needed
> (the function's frames are resumed one by one).

Do you feel like adding this explanation to the D07.1 report? :-)


  <radix> A VoIP server "powered entirely by stabbing, that I made
          out of this gun I had"                -- from Twisted.Quotes

More information about the Pypy-dev mailing list