I'm a lot more interested in architectures that scale well on both multi-core machines and across blade servers, data centers and clouds than in multi-threaded architectures that may (or may not) scale on a single address space. A multi-threaded image comes up short here when compared to Erlang-like approaches.<br>
<br>-david<br><br><div class="gmail_quote">On Mon, Jul 7, 2008 at 1:07 AM, Jason Johnson <<a href="mailto:jason.johnson.081@gmail.com">jason.johnson.081@gmail.com</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;">
On Mon, Jul 7, 2008 at 8:00 AM, Peter William Lount <<a href="mailto:peter@smalltalk.org">peter@smalltalk.org</a>> wrote:<br>
> Hi,<br>
<div class="Ih2E3d">><br>
> I get that you think that it's a clean model for concurrency. I don't buy it<br>
> though.<br>
><br>
> Please describe it fully and in detail. Thank you.<br>
<br>
</div>Why does he need to describe this again? You could look at past<br>
threads or you could look at some of the *actual research on this<br>
subject*. Here is a paper from 2006:<br>
<br>
"The problem with threads"<br>
<a href="http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.html" target="_blank">http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.html</a><br>
<div class="Ih2E3d"><br>
> You'll allow multiple non-native smalltalk green threads right?<br>
<br>
</div>I wouldn't. This is a big source of bugs and confusion. I would<br>
personally change the ST process model to have "processes" instead of<br>
"threads" (i.e. nothing is shared between them).<br>
<div class="Ih2E3d"><br>
> Your "simplified" model doesn't seem to be simple at all. You'd have to<br>
> prevent any green threads within the native thread.<br>
><br>
> You then push the concurrency processing problems off on to multiple images<br>
> and now the problems become data base like concurrency issues and<br>
> serialization issues and object identity/version issues.<br>
><br>
> You've not gained much and you've limited others needs in the process.<br>
<br>
</div>Here you just seem to be going off on a tangent without even knowing<br>
what solution he had in mind. Wonderfully productive way to argue.<br>
<br>
</blockquote></div><br>