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 < <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 
For more options, visit

Reply via email to