gen_server:cast/2 vs !
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) ->
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