gen_server:cast/2 vs !

Sean Hinde sean.hinde@REDACTED
Sat Oct 4 03:24:56 CEST 2003

On Saturday, October 4, 2003, at 01:37  am, Vance Shipley wrote:

> Today I am wondering why I would make an interface to a process
> with gen_server behaviour use gen_server:cast/2 to send it's
> asynchronous messages.  Why not just <Pid> ! AsynchMessage?
> Is it so wrong to have a gen_server process use handle_info for
> lots of things?  The gen_servers and gen_fsms which communicate
> with my cnodes pretty much have to unless I put a proxy in.
> What will I gain from the cast function?

I like to use the convention that cast messages to this process are 
only sent using the API of this gen_server module:


send_async_req(Pid, Req) ->
	gen_server:cast(Pid, Req).

  This has  some major maintenance benefits:

1. It separates out API related traffic from other messages - I know 
where to look in the callbacks, I know that this set of messages must 
have arrived via the API, and I know that handle_info is dealing with a 
different kind of message (timers, port data etc)

2. It makes it extremely easy to track back months later to where the 
messages are coming from by simply grepping for the places the API is 

These maintenance advantages to me are a pretty overwhelming reason to 
avoid bypassing the gen_server abstraction with !


More information about the erlang-questions mailing list