On Thu, Mar 8, 2018 at 10:37 AM Haddock <ffm2...@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.
