Thank you for a very interesting and informative analysis. I must admit that I tend to lump together Erlang/OTP as "Erlang" and see solutions in that context. In a way, I feel as if using Erlang "standalone" without OTP is very roughly analogous to using C++ without the STL: it can be done, but why on earth would one want to?<br>
<br>I agree that the last answer didn't answer much. What I was trying to say is that the architecture should perhaps be redesigned to fit a Functional Programming/Message Passing paradigm and infrastructure, but I couldn't suggest precisely how because there was almost no information about the original architecture. So in retrospect I wound up saying nothing useful.<br>
<br>As a final note, let me say that I was thrown in to the deep end in Erlang by having to learn Erlang and OTP concurrently (pun intended) because I had to create a production system in a short period of time. This is why it's a bit hard for me to separate the two.<br>
<br>Thanks again for clearly identifying the core issues, as you usually seem to do.<br><br><off-topic>One last thing: I read the Ethics of Belief after poring over one of your posts recently, and was exceptionally impressed with the gentleman's writing and philosophy, with which I strongly agree. In that regard, I'd like to misquote John Stuart Mill, namely, "A foolish <i>certainty</i> is the hobgoblin of little minds". (Actually, I think my version is a slight improvement ;) I am unfortunately seeing the mechanism of insufficiently examined beliefs at work today, resulting in the persecution of a friend of mine by way of (the almost totally belief-based) Shaken Baby Syndrome. So the essay really resonated deeply with me. I daresay William K. Clifford would have had a lot to say about this. I wish he were still alive to do so. Bertrand Russel too.</offtopic><br>
<br><div class="gmail_quote">On Tue, Jul 1, 2008 at 12:48 AM, Richard A. O'Keefe <<a href="mailto:ok@cs.otago.ac.nz">ok@cs.otago.ac.nz</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"><br>
On 1 Jul 2008, at 3:42 pm, Edwin Fine wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Richard,<br>
<br>
I'm new to Erlang and FP, and I want to learn from my mistakes or misunderstandings. Please could you critique the suggestion I sent in regarding this problem? The fact that nobody commented means either that it was (a) totally naive and not worthy of comment (or to spare my feelings), or (b) such a good idea that all were rendered speechless with admiration. Somehow the probability of (b) seems rather low. So... where did I go wrong?<br>
</blockquote>
<br></div>
Let's recapitulate. If I've found the right message,<br>
Edwin Fine had three suggestions:<br>
<br>
• Create a gen_fsm that controls all the collections.<div class="Ih2E3d"><br>
The collections could be ETS tables or gen_servers wrapping ETS tables.<br>
Under normal use, messages are sent to the fsm to update the collections<br>
individually. When the time comes to require consistency across the<br>
collections, send a message to the fsm to get the collective state data.<br>
The fsm goes into a different state while it gathers the data.<br>
This state would reject requests to update the collections (or wait until<br>
the state changes), although reads would still be allowed.<br>
On getting the result, the state changes back to allow updates again.<br>
• Create a memory-only Mnesia table for each collection, and use Mnesia<br>
transactions to get the multiple values atomically.<br>
• Change the architecture of the current lock-oriented program to make<br>
better use of Erlang's features.<br>
<br></div>
From bottom to top:<br>
- The last one doesn't really answer the orignal poster's question.<br>
At least, imagining myself in the OP's shoes, I would not find that<br>
answer informative. Change it HOW? WHICH features? In what way better?<br>
<br>
- The second one might well be the right thing to do in a production<br>
system. However, someone who is still struggling with how to use messages<br>
probably doesn't want to be told to learn another huge great thing, and<br>
might well get the impression that message passing wasn't much good<br>
after all.<br>
<br>
- As for the first one, it seemed to me that in order to do that, you'd<br>
pretty much have to solve the original problem anyway, plus you would<br>
have to come to grips with behaviours, callbacks, gen_fsm, and a lot of<br>
stuff which is practically very very useful, but not something to be<br>
understood in five minutes.<br>
<br>
I suppose I can summarise it as "You gave OTP answers to what I saw as<br>
an Erlang question". I may well be completely mistaken about where the<br>
OP was coming from, but I understood the question to be specifically a<br>
question "how can the OP solve this problem directly using message passing."<br>
OTP answers are very often precisely the right answers, so don't stop<br>
giving them.<br>
<br>
<br>
</blockquote></div><br><br clear="all"><br>-- <br>The great enemy of the truth is very often not the lie -- deliberate, contrived and dishonest, but the myth, persistent, persuasive, and unrealistic. Belief in myths allows the comfort of opinion without the discomfort of thought.<br>
John F. Kennedy 35th president of US 1961-1963 (1917 - 1963)