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 <javascript:>> > 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.
