<br><br><div class="gmail_quote">On Mon, Jul 7, 2008 at 8:08 PM, Andreas Raab <<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Peter William Lount wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Why prevent others from having their needed multiple native threads?<br>
<br>
</blockquote>
<br></div>
It's not about preventing anything. If you have a proposal for how to do multiple threads per image I will most definitely listen, and if it is a reasonable proposal (i.e., one that can be implemented with bounded resources) I will even try to find funding for it. However, until such a time that there is a proposal I will drop this pointless discussion since, simply put, there is nothing to discuss here. The only available path at this point is by using one native thread per image and consequently that's what's going to happen.<br>
</blockquote></div><br><br>If I were working on a concurrent VM, I'd just barge ahead and parallelise the Squeak VM:<br>
<br>
* I'd refactor the VM so that multiple copies of the interpreter state
could be held in the heap. I'd design it so that each pthread would run
one instance of the standard Squeak interpreter, and so that each interpreter runs
multiple green theads as it does now. This makes forking a
very cheap operation and allows for having as many green threads as would fit in memory.<br>
* I'd then see what needs fixing in the VM / plug-ins / image to make
it work. I'd probably start with the simple approach: an evil but simple global VM lock for memory writing operations, and no changes to GC. Later, we can revisit this to make it scale better.<br>
* I'd then spend the next decade finding and fixing concurrency bugs.<br clear="all"><br>What I'm actually going to do is:<br><br>* Modify the Squeak schedular to simulate concurrency better and bring up lots of concurrency bugs in the image.<br>
* Spend a decade fixing concurrency bugs in the image.<br>* Write enough concurrent code to make it worth having a concurrent VM.<br>* Sell that code, make a lot of money.<br>* Buy the rights to Gemstone or some other high-performance, concurrent VM.<br>
* Port my code to that instead.<br>* Make a lot more money.<br><br>
Gulik.<br><br clear="all"><br>-- <br><a href="http://people.squeakfoundation.org/person/mikevdg">http://people.squeakfoundation.org/person/mikevdg</a><br><a href="http://gulik.pbwiki.com/">http://gulik.pbwiki.com/</a>