I had a related question <https://elixirforum.com/t/handle-call-and-actor-model/10726/8> asked on Elixir Forum:
Is handle_call part of the Actor Model? Since it sequentialize/synchronize things, is sound a bit like CSP (to me). An answer provided by Joe Armstrong (one of Erlang inventors) states that indeed CSP influenced the design of Erlang and at the time, they were not familiar with Actor Model. On Saturday, March 10, 2018 at 12:51:18 PM UTC+3:30, Anto Aravinth wrote: > > Thanks a lot, that was a solid information shared by everyone. > > On Thursday, 8 March 2018 17:51:55 UTC+5:30, Jesper Louis Andersen wrote: >> >> On Thu, Mar 8, 2018 at 10:37 AM Haddock <ffm...@web.de> wrote: >> >>> The fundamental problem with asynchronous programming is that >>> asynchronous messages that depend on each other from the application logic >>> "may not meet" and miss each other. Let's say, several threads start to >>> search through a pile of data starting from different offsets. Somehen one >>> thread has found the needle, now the other threads do not need to continue >>> searching any more. How to tell them to cancel their search? This is not >>> easy and therefore is a good simple example to show problems in >>> asynchronous programming, but only a simple one. There are hell of problem >>> situations of similar nature with asynchronous programming ... >>> >>> >> On particular weakness of the pure actor models are that they always >> process messages in an unordered fashion. This is yet another of those >> cases where "Erlang doesn't implement the actor model". Not only can you >> select which messages to process in a given state. You also have a FIFO >> guarantee among pairs of processes. And this is crucial because it allows >> you to limit the state space of possible events that can occur. >> >> As for the search-for-a-needle problem, you need either something like >> package "context" in Go, or links like in Erlang. You simply link together >> all the searchers. The first one to find a needle, sends off a message and >> then terminates. Because it is linked to the other processes, they also >> terminate. If two processes both find a needle at the same time, you have >> two answers, but you can do whatever you want with that in the receiver. >> Note that in Erlang, because of process isolation, abrupt termination is >> usually safe. If you have cleanup to do, you can always ask the process to >> turn the termination into a message, but then you are also obliged to >> periodically taste your mailbox to make sure there are no such message in >> it. >> >> I agree that asynchronous messaging is harder than a single thread or >> synchronous messaging. But: >> >> * It is necessary in a lot of cases. >> * It is very often faster because there is a lot less contention going >> on. Especially in the latency department. >> * Properly written, it tend to be more flexible. >> * If it schedules preemptively, then async systems are more robust >> against a few rogue parts of the system taking too long time. >> >> >> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
