Christopher Smith wrote:
Andrew Lentvorski wrote:
First, nothing may be shared. All communication is by messages that
are copied. This has interesting performance tradeoffs.
Not really. There is no requirement that an actual copy happen.
Since there is one single Erlang implementation and it serializes and
copies messages, that's as close to a requirement as one gets.
As I said, Erlang needs a second implementation before I believe that it
can survive.
There is a comparison between Gambit/Termite and Erlang where you
see that Erlang benefits as long as the messages are small and starts
to die when the messages get big--Gambit/Termite is the reverse.
Erlang's runtime does need to be optimized better for larger messages.
Not necessarily. Erlang has its market niche and that market niche
doesn't need larger messages.
That's what a second implementation would be useful for. To knock out
some of the baked in compromises that may not fit outside of its
specific domain.
Second, it puts watchdogs over things and if they lock, it kills and
restarts them. That solves the *symptom*, but not the problem.
Again, the halting problem... sometimes all you can solve is the symptom.
Disagree. Your brain does not always reboot because you got a bump on
the head. The problem is that most programs do not try to recover
gracefully in the case of failure.
Something as simple as "out of memory" causes better than 99% of all
programs to die with horrible corruption. There is no reason for that
other than the fact that no one takes the time to code it.
Third, all messages are received asynchronously, so you have to
account for that outright in your coding style.
Isn't the assumption that messages can be passed instantly between two
nodes on of those "Myths of distributed computing"?
At no point did I say "instantly".
The problem is rarely lack of instantly. It normally is lack of ordering.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
