| Author |
Message |
|
| bkl |
 Posted: Wed Feb 18, 2009 3:18 am |
 |
|
|
User
Joined: 17 Aug 2008
Posts: 19
|
What is the difference between implementing an asynchronous message using handle_cast() v.s. handle_info() in gen_server? Similarly, there are handle_info() and handle_event() in gen_fsm. What should be the designing guideline of choosing one against another implementation? What's the justification of two separate API for handling asynchronous messaging?
Thanks in advance,
Bkl. |
|
|
| Back to top |
 
|
| uwiger |
| Posted: Thu Feb 26, 2009 9:31 am |
|
|
|
User
Joined: 03 Jul 2006
Posts: 604
Location: Sweden
|
bkl wrote: What is the difference between implementing an asynchronous message using handle_cast() v.s. handle_info() in gen_server? Similarly, there are handle_info() and handle_event() in gen_fsm. What should be the designing guideline of choosing one against another implementation? What's the justification of two separate API for handling asynchronous messaging?
The rule of thumb is that if you are casting to your own gen_server, you use gen_server:cast(). You use handle_info() to process messages whose format you cannot control, and there should be no unknown casts to your server. |
|
|
| Back to top |
|
| bkl |
| Posted: Sat Feb 28, 2009 7:51 pm |
|
|
|
User
Joined: 17 Aug 2008
Posts: 19
|
Wiger,
Thanks for the reply. Is this just a guideline, or there is some solid technical reason behind this "rule of thumb". For example, if my server is monitoring or linking w/ another process, then should handle_cast() or handle_info() process the exit signal (i.e.{'EXIT',...})?
Bkl. |
|
|
| Back to top |
|
| uwiger |
| Posted: Sun Mar 01, 2009 12:21 am |
|
|
|
User
Joined: 03 Jul 2006
Posts: 604
Location: Sweden
|
bkl wrote: Wiger,
Thanks for the reply. Is this just a guideline, or there is some solid technical reason behind this "rule of thumb". For example, if my server is monitoring or linking w/ another process, then should handle_cast() or handle_info() process the exit signal (i.e.{'EXIT',...})?
To be really honest, it's mainly my own rule of thumb. 
I just think it makes a lot of sense. The general guideline is to not let your protocol escape out of the module, i.e. you hide the calls and casts behind API functions. By extension, you shouldn't have any unknown casts. This leaves the messages that are either predefined (like timer messages, DOWN, EXIT, etc.) or just come to you out of the blue (in a robust system, it's a good idea not to crash on unknown messages). They all go in handle_info().
In other words (to answer your question), handle_cast() cannot deal with EXIT messages etc, since they are not tagged as casts: {'$gen_cast',Msg}. It only deals with messages sent using gen_server:cast/2 (or faked to look as such). |
|
|
| Back to top |
|
| bkl |
| Posted: Sun Mar 01, 2009 7:53 am |
|
|
|
User
Joined: 17 Aug 2008
Posts: 19
|
Wiger,
Got it. Thanks again.
Bkl. |
|
|
| Back to top |
|
| wuji |
| Posted: Wed Aug 22, 2012 7:20 am |
|
|
|
User
Joined: 10 Aug 2012
Posts: 654
|
of unsuspecting malware-infected individuals without online access.What temporary Internet servers, servers, cheap jordans servers, you ask? They might have been connecting you to
YouTube, and -- ahem! -- ABCNews.com for the last month, month, cheap polo shirts month, and you didn't even know it. Really.Why is this
It all has to do with a piece of computer computer jordan 6s computer malware called DNS Changer.It started in 2007, when a
of hackers -- six Estonians and one Russian -- allegedly allegedly [h2]cheap replica *beep*[/h2] allegedly started masquerading as Internet advertisers who were paid by
click, according to an 2011 indictment from the U.S. Attorney Attorney cheap polo shirts Attorney General's Office in the Southern District of New York. |
|
|
| Back to top |
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
