[Stackless] no gil?

[Andrew Francis]

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  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stackless.com/pipermail/stackless/attachments/20140418/a5b93527/attachment.html>