<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Jason Johnson wrote:
<blockquote
 cite="mid:aa22f0200710250918g68d0d86ar6be97f47cd4b8dea@mail.gmail.com"
 type="cite">
  <pre wrap="">On 10/25/07, Matej Kosik <a class="moz-txt-link-rfc2396E" href="mailto:kosik@fiit.stuba.sk">&lt;kosik@fiit.stuba.sk&gt;</a> wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Anyone followed links that Andreas gave?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Yes, some of it.  Looks like it's based on the futures model.

  </pre>
  <blockquote type="cite">
    <pre wrap="">  (Erlang does not solve these problems.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
No one *solves* these problems, the actor model Erlang uses is just a
good way of dealing with most of the cases.


  </pre>
</blockquote>
Hi,<br>
<br>
"...most of the cases"? Hardly! It barely scratches the surface.<br>
<br>
The "process-based model of concurrency" - as used in Erlang - is but
one approach in a wide range of techniques that provide solutions for
concurrency. It doesn't solve every problem in concurrency - I don't
even think that they claim that for it. If they do please show us where.<br>
<br>
Further the example of the one million object graph being processed by
10,000 compute nodes processing the problem is that you don't know in
advance how to slice up the data. If you can know in advance how to
slice up the data then you've simplified and possibly optimized the
problem solving. However, that's the problem, slicing up real world
data object sets that are highly interconnected with each other and
processing them in parallel. That's an example of a more general case.
There are other examples that won't compute with the slice em and dice
em approach using the process-based model of concurrency.<br>
<br>
Peter<br>
</body>
</html>