<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:12pt"><div id="yiv6922684471"><div><div style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255); font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 12pt;"><div id="yiv6922684471yui_3_13_0_10_1397833262376_8"><span id="yiv6922684471yui_3_13_0_10_1397833262376_14">Hi Kristjan and Folks:</span></div><div id="yiv6922684471yui_3_13_0_10_1397833262376_8" style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;"><br clear="none"></div><div class="yiv6922684471yahoo_quoted" id="yiv6922684471yui_3_13_0_10_1397833262376_10" style="display: block;"><div class="yiv6922684471yui_3_13_0_1_1397833262376_18749"
 id="yiv6922684471yui_3_13_0_1_1397833262376_18798" style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 12pt;"><div class="yiv6922684471yui_3_13_0_1_1397833262376_18750" id="yiv6922684471yui_3_13_0_1_1397833262376_18797" style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 12pt;"><div class="yiv6922684471y_msg_container" id="yiv6922684471yui_3_13_0_1_1397833262376_18796">>At PyCon I was approached by a core developer of CPython who asked me this:<br clear="none">>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?<br clear="none"><br clear="none">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.</div><div class="yiv6922684471y_msg_container" id="yiv6922684471yui_3_13_0_1_1397833262376_18796"><br></div><div class="yiv6922684471y_msg_container" id="yiv6922684471yui_3_13_0_1_1397833262376_18796">I think Go is an example of what a multi-core Stackless would look like. </div><div class="yiv6922684471y_msg_container" id="yiv6922684471yui_3_13_0_1_1397833262376_18796"><br></div><div class="yiv6922684471y_msg_container" id="yiv6922684471yui_3_13_0_1_1397833262376_18796">>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.</div><div class="yiv6922684471y_msg_container" id="yiv6922684471yui_3_13_0_1_1397833262376_18796"><br clear="none"></div><div class="yiv6922684471y_msg_container" id="yiv6922684471yui_3_13_0_1_1397833262376_18796">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."<br clear="none" id="yiv6922684471yui_3_13_0_1_1397833262376_20404"><br clear="none">>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)?  </div><div
 class="yiv6922684471y_msg_container" id="yiv6922684471yui_3_13_0_1_1397833262376_18796"><br clear="none"></div><div class="yiv6922684471y_msg_container" id="yiv6922684471yui_3_13_0_1_1397833262376_18796">I think it depends on how much one tries to abstract away in the runtime. Or what programming style one promotes.</div><div class="yiv6922684471y_msg_container" id="yiv6922684471yui_3_13_0_1_1397833262376_18796"><br></div><div class="yiv6922684471yqt3690195553" id="yiv6922684471yqtfd26224"><div class="yiv6922684471y_msg_container" id="yiv6922684471yui_3_13_0_1_1397833262376_18796">>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.</div></div><div class="yiv6922684471y_msg_container" id="yiv6922684471yui_3_13_0_1_1397833262376_18796"><br clear="none"></div><div class="yiv6922684471y_msg_container" id="yiv6922684471yui_3_13_0_1_1397833262376_18796">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 <span style="font-size: 12pt;">channels become threadsafe, primitives that are built on top of them, don't have to worry.</span></div><div class="yiv6922684471y_msg_container" id="yiv6922684471yui_3_13_0_1_1397833262376_18796"><br></div><div class="yiv6922684471y_msg_container" id="yiv6922684471yui_3_13_0_1_1397833262376_18796">Cheers,</div><div class="yiv6922684471y_msg_container" id="yiv6922684471yui_3_13_0_1_1397833262376_18796">Andrew  </div></div><div
 class="yiv6922684471yqt3690195553" id="yiv6922684471yqtfd97974"> </div></div><div class="yiv6922684471yqt3690195553" id="yiv6922684471yqtfd97561">  </div></div><div class="yiv6922684471yqt3690195553" id="yiv6922684471yqtfd08546">
 </div></div></div></div></div></body></html>