Hi Kristjan and Folks: >At PyCon I was approached by a core developer of CPython who asked me this: >If we had a hypothetical GIL-less CPython, would stackless (tasklets or >co-routines) still be a >useful constructs or would real threads be sufficient?
Yes tasklets would be useful constructs for two reasons. First a OS-thread uses more resources than a tasklet. Secondly and I think far more important reason, tasklets/channels are a simpler and more powerful concurrency construct. I think Go is an example of what a multi-core Stackless would look like. >3) Co-operative scheduling: To be able to run multiple execution >contexts without pre-emptive >switching is a huge win. If your problem is >such that you are IO bound anyway and cpu doesn"t >matter much then this can >be a very attractive programming model. Co-operative scheduling in the form of synchronous channels with buffers is a very simple and powerful concurrency model. John Reppy has a nice explanation of the attractiveness of synchronous channels in "Concurrent Programming in ML." >Any other thoughts? How would applications of stackless python be different >if there were no >GIL, i.e. threads could run in parallel (but tasklets were >co-operatively scheduled in each thread >as before)? I think it depends on how much one tries to abstract away in the runtime. Or what programming style one promotes. >For one thing, I know that many synchronization privmitives currently written >using channels >would need re->writing. They currently rely on tasklet.atomic >for atomicitiy which also prevents >thread switching (by preventing the thread >from releasing the GIL). If there were no GIL, we >would need to use >additional locking if we wanted our stackless locking primitives (e.g. >>stacklesslib.locks) to work between tasklets of different threads. Again, if looking at Go's runtime source code is any indication, in a multi-core world, Stackless's channel implement will get much more complicated. Perhaps since channels become threadsafe, primitives that are built on top of them, don't have to worry. Cheers, Andrew
_______________________________________________ Stackless mailing list Stackless@stackless.com http://www.stackless.com/mailman/listinfo/stackless
