Stackless is interesting, but I found it to be a little unwieldy when I wrote a volume visualization test. When each task needs access to the entire volume of data, Stackless gets REALLY slow. I didn't look through the Stackless internals the way I looked into Erlang, but the slowdown was undeniable.

Again, for massive datasets, accessed by many cores over a massive number of threads, it needs a little more development.

TEST ALGORITHM:

Standard Volume ray casting. Each pixel processed separately. Ray casted through volume with alpha based early ray termination.

That's an excellent test algorithm because of the shared memory issues. Might be better if the rays affected the environment -- say laser beams. (For some reason I have a picture of sharks with laser beams)

Ray-tracing is a nice, simple problem domain -- enough to be complicated, but not too complicated.

Isn't stackless not truly concurrent since it's still beholden to the Python GIL?

Or is that not the case?

Stackless is an example of the communicating sequential process model, not concurrency. You avoid all the issues around locking etc because switching between processes (tasklets) is explicit - it's cooperative multitasking not preemptive. It's a very nice language but doesn't help at all with running on multiple cores. Once you start having multiple processes running simultaneously and shared mutable state you have to start worrying about things like locks. Erlang nicely sidesteps the problem by not having mutable variables.