Andrew Lentvorski wrote: > 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. Agreed, although I thought it only serialized messages when they had to cross Unix IPC boundaries >>> 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. Yes, but that artificially limits it to being a niche language. >>> 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. It's hard to state definitively how the brain works, but there is some evidence to suggest it can and does work much like Erlang does in this regard. > The problem is that most programs do not try to recover gracefully in > the case of failure. Erlang does using a checkpointing mechanism, with Erlang processes (much lighter weight than Unix processes) providing the demarcation between checkpoints. > 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. Here I have to disagree with. For a whole host of programs, running out of memory is an indication that something is seriously wrong. Dying is an excellent thing to do in that circumstance, and a LOT of code does exactly that, leaving the system in an appropriate state. The normal case where "out of memory" shouldn't kill you is if you have a dynamically sized cache or similar structure which can be shrunk to free up more room. >>> 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. An async message that triggers a response from the recipient (which one then waits for) achieves all the goodness of a synchronous message. The tricky part is doing asynchronous messages, which is why it is nice that Erlang has them. Similarly, Java's RMI, ONC RPC, DCE RPC, IIOP, DCOM, SOAP, XML-RPC, etc., provide relatively straightforward synchronous messaging. It's not like it is hard to find. Just hard to do right.
--Chris -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
