Erlang/OTP Callback Modules

Apologies for my April 19, 2009 post. For one thing, it’s much too dense. And worse, it’s wrong — at least seven of the last eight paragraphs.

Reading Erlang source really shouldn’t be rocket science. But I’m still struggling to follow the flow-of-control through Erlang applications.

One problem, for me, is this concept of “callback module.” I think I understand it, but the more I think about it the less confident I feel. I’ve tried to find a definition in Google, but failed. It seems to be one of those terms that everyone tosses around thinking that everyone else understands it.

But if I’m hazy, chances are there’s another Newbie or two out there scratching his/her head as well.

Problem for this Newbie is that the concept of “callback module” implies that something is going on behind the curtains. If I’m not all that clear about what’s going on back there, how can I be clear about what’s going on in the foreground?

So here’s my Newbie insight for the day. Caution: it may be wrong. If so, I beseech any passing Erlang wizard to set me straight.

Behaviours in Erlang/OTP are functional templates of oft-repeated code patterns, e.g., servers, finite-state machines, events, supervisors, and applications.

Callback modules fill in the slots in these templates to round out functionality for specific purposes. The “behaviour” is the generic, or abstract, part of the functionality. The “callback module” is the means through which the programmer tailors a behavior for specific application.

So how do we find out what’s going on behind the curtain? Erlang/OTP docs should certainly be our first stop:

Gen_Server Behaviour

“The client-server model is characterized by a central server and an arbitrary number of clients. The client-server model is generally used for resource management operations, where several different clients want to share a common resource. The server is responsible for managing this resource.”

Gen_Fsm Behaviour

“A finite state machine, FSM, can be described as a set of relations of the form:

“State(S) x Event(E) -> Actions(A), State(S’)

“These relations are interpreted as meaning:

“If we are in state S and the event E occurs, we should perform the actions A and make a transition to the state S’.”

Gen_Event Behaviour

“In OTP, an event manager is a named object to which events can be sent. An event could be, for example, an error, an alarm or some information that should be logged.”

Supervisor Behaviour

“A supervisor is responsible for starting, stopping and monitoring its child processes. The basic idea of a supervisor is that it should keep its child processes alive by restarting them when necessary.”

Applications

“When we have written code implementing some specific functionality, we might want to make the code into an application, that is a component that can be started and stopped as a unit, and which can be re-used in other systems as well.”

I’ll pick up on iserve again tomorrow; and try to view it from high overhead with these “behaviours” in mind.