[PEAK] Greenlets: an interesting development

[Phillip J. Eby]

Due to recent threads on python-dev and c.l.py about coroutines, I heard 
about an interesting part of the current Stackless Python known as 
"greenlets".  Previously, I had thought that this wasn't usable without 
Stackless, but it appears that it actually *is*.  This evening I 
successfully built the 'greenlet' module for Python 2.2, and ran one of its 
demos: it worked like a charm.

'peak.events' right now uses code that looks like this:

     yield anEventSource; result = events.resume()

With 'greenlets', this code could look like:

     result = anEventSource.wait()

Or even just:

     result = something()

And further, it wouldn't require threads, or "generators all the way down".

Greenlets work by manipulating the C stack, copying portions of it in and 
out of the heap.  Unlike simple stack-switching, however, it doesn't simply 
copy huge blocks of stack.  For example, starting a new Greenlet doesn't 
require any stack copying at all, and there are other circumstances where 
copying is avoided as well.

I don't have any compelling reason to want to redo peak.events "task" 
system at the moment, but it's potentially quite interesting for the 
future, because it allows the use of code that *wasn't* written with 
peak.events in mind, and doesn't cause knowledge of peak.events to spread 
throughout the code.

I'm curious whether anybody else has any experience/comments on the 
greenlet system, and its appropriateness for use in PEAK.  I'm personally 
worried that it might be incompatible with any extension module that issues 
asynchronous or threaded callbacks using pointers to stack-allocated data, 
since in principle the allocated data could get swapped out.  I'm also 
mildly concerned about its cross-platform nature, or lack thereof.  The 
current platforms are:

    PPC Mac OS/X
    PPC Unix
    Sparc/Sun
    X86 MSVC
    X86 Unix
    S390

Of course, that covers quite a few "enterprise" platforms, including the 
ones most important to me.

Anyway, feedback would be nice.  This looks like an attractive alternative 
to direct use of 'events.Task()'s, and it could work for other things, too, 
like converting an output streams into an input iterator.