AF>This may be tangential to the discussion but in the past, I have used the stackless.py module in conjunction with AF>CPython and greenlets to rapidly prototype parts of Go's model that are not present in Stackless, i.e. the select (ALT) AF>language feature. Rob Pike and Russ Cox were really helpful in answering my questions. Newer stackless.py AF>implementations use continuelets so look for an older PyPy implementation. 

AF>I have also prototyped a subset of Polyphonic C# join patterns.  After I got the prototype running, I had an interesting AF>discussion with the authors of "Scalable Join Patterns."

>Yes saw that. And actually some part of the Task code is based on stackless.py  but using greenlets, >Channels have been slightly modified to be thread-safe and support buffering. Did you release your code >somewhere ? It could be interesting to put the experience further.

You may be mistaking my work with someone else.

I didn't add buffering but that t is relatively easy to do without altering Stackless Python's internals. However I believe that synchronous channels with buffering is a simple and powerful concurrency model. Go's implementers got it right. John Reppy (currently a NSF director) talks about synchronous channel's power in a Concurrent ML book. 

If  you go to to the Stackless repository example page

you will find the code for a modified stackless.py that implements Go's select statement. 

Since I am giving a talk in Toronto soon, I will soon release a new version of the join pattern version with documentation and examples. The code is about a year old and I have learnt new things.  I can mail you an archive and you are free to play with it and ask questions. 

Since this is somewhat off-topic, the reason I mention all this is that if you want to experiment with a Go style system, I think it easiest to work from something like stackless.py and greenlets than start from scratch. 

Cheers,

Andrew