I just read the Dalke diary entry and I have a question. <div><br></div><div>I was thinking that the big (as in really big) leg up that Go has on Stackless is the fact that Go can take advantage of multiple cores on the same machine or even multiple machines working together without writing your own load-balancing and etc and what-have-you, which would be a major leg up over pretty much every language currently in existence.<div>
<br></div><div>Would it make a difference if Dalke&#39;s goroutines were running on an 8 core processor rather than a single core? Stackless has the advantage of having no thread overhead whatsoever because it doesn&#39;t deal in system threads like Go does, and on a single core couldn&#39;t that make all the difference?</div>
<div><br></div><div>More importantly, wouldn&#39;t he have wanted to choose an example where a total solution could be built by passing partially completed pieces of a solution between thousands of independently executing routines? Isn&#39;t that what Go was built to do? Of course, I have not read the Go specification. I thought the whole point of Go was parallel processing and computing, which Stackless isn&#39;t made to do anyway.</div>
<div><br></div><div>Andrew</div><div><br><div class="gmail_quote">On Sun, Apr 25, 2010 at 12:00 AM, Andrew Francis <span dir="ltr">&lt;<a href="mailto:andrewfr_ice@yahoo.com">andrewfr_ice@yahoo.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi Folks:<br>
<br>
I just finished a new version of my implementation of select (I actually call it an eventHandler) using stackless.py. Let me write some more tests and examples before posting. I don&#39;t think I will have time to implement the minimal hooks in C Stackless Python by Monday. Now time to write slides. I would like to solicit my fellow Stackless Pythonistas for some advice.<br>

<br>
Anyhow, I believe Richard in his blog, discusses the difference in approach between Stackless and Go. It seems to me that Stackless by<br>
exposing more of the scheduler to the programmer, is promoting a tool box approach - if you don&#39;t like the way the scheduler works, there is enough API and classes to do what you want in a module. Also Stackless is more trusting and puts more responsibility on the shoulders of the programmer. I haven&#39;t written any serious Go programmes yet but Stackless seems to me more flexible. Does this seem to be a reasonable assessment of Stackless philosophy?<br>

<br>
The other thing in the Pike paper and in Go, is the attempt to put a certain amount non-determinism into the system, to prevent programmers from manipulating the system. On the other hand, from reviewing Kristjan&#39;s EVE talk, fairness (tasklets run in the order that they are ready) seems to a very important concept in Stackless design. Again, would this be an accurate statement?<br>

<br>
As for the direction of Stackless? I will assume with integration with Psyco, this will be one less reason to write C extensions?<br>
<br>
Any other comments?<br>
<br>
I will probably ask similar questions in the Go mailing list.<br>
<br>
Cheers,<br>
Andrew<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Stackless mailing list<br>
<a href="mailto:Stackless@stackless.com">Stackless@stackless.com</a><br>
<a href="http://www.stackless.com/mailman/listinfo/stackless" target="_blank">http://www.stackless.com/mailman/listinfo/stackless</a><br>
</blockquote></div><br></div></div>