<br><br><div class="gmail_quote">On Mon, Jul 7, 2008 at 4:32 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;">
I think it's best to let each developer-user choose how many native threads per image and how many images are loaded and which images are loaded. After all it's their program. Isn't our job as language and systems designers to provide them with the tools that they need to build the systems that they want to build? I think so. What do you think?<br>
</blockquote>
<br></div>
Everything you say, to the letter, can and has been said about manual memory management. The point you're apparently not getting is that the "one native thread per image" is not only a workaround to avoid some very nasty issues down in the VM, it also provides a clean *model* for concurrency. No such model exists for shared state concurrency which is the real problem - since all synchronization is manual, it is pretty much impossible to write large scalable systems correctly with manual locks and mutexes. Just as it is impossible to write large scalable systems correctly with manual memory management.<br>
<font color="#888888"></font></blockquote><div><br><br>It's not *that* hard to write a large, scalable, concurrent systems using Processes and Semaphores. Sure, at times it can be difficult with horrible bugs that take a decade to manifest, but if you use consistent patterns and encapsulate complex behaviour well, it is quite tractable.<br>
<br>There are a few nice abstractions one could use. Let me know if you know of any ones not here: <a href="http://gulik.pbwiki.com/Parallel+processing">http://gulik.pbwiki.com/Parallel+processing</a><br><br>Gulik.<br></div>
</div><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>