[Python-Dev] Stackless Python

[Phillip J. Eby]

At 10:50 AM 6/2/04 -0700, Guido van Rossum wrote:
> > > Bob Ippolito wrote:
> > >>> However, JCSP uses java.lang.Threads to implement
> > >>> concurrency. So they are completely unlike Stackless' tasklets
> > >>> in their implementation strategy.
> > >> So what, if the API is the same?
>
> > In my quick attempt to do CSP on top of CPython threads I learned that:
> > - It's not as easy as it sounds to get deterministic behavior out of
> >   threads, and debugging threaded python apps is no fun.
> > - When it does work, the performance sucks compared to Stackless.
>
>The same is probably true for JCSP.  I don't want a feature that can
>only be implemented efficiently by using assembler or some other
>platform-specific hack (and most uses of longjmp() fall in that
>category, despite its status as an ISO standard library function!).
>Especially if the proponents keep using efficiency as the most
>important property of the feature.

I personally think that deterministic task-switching is more relevant than 
raw speed.  Being able to create hundreds or even thousands of lightweight 
tasks is also very useful.

Right now I can do both of these using generators in CPython 2.2 or better, 
so the only things (IMO) that Stackless is offering to add are:

1. dropping the need to write tasks solely in the form of "generators all 
the way down"

2. a simpler syntax: yields are expressed as calls, rather than as a 
'yield' statement followed by various magical idioms.

I currently have code that doesn't hesitate to spawn generator-based 
tasklets for simple condition monitoring tasks, and I have no idea in 
practice how many of these tasklets might be running in my code, but I'm 
pretty sure it's more than I'd want to have threads running for.  However, 
if threads only had to be used when yielding code was called from 
non-yielding code, or vice versa, I'd probably be okay with it.  Such 
boundaries aren't all that common in my experience to date using 
generator-based tasklets.