Author

Vance Shipley

Introduction

Behaviours

Behaviour modules encapsulate some certain functionality for reuse by other modules. The definition of a behaviour includes not only it's exported functions but a list of functions which a callback module must implement. OTP includes several behaviour modules with the most common being gen_server and gen_fsm.

Using gen_fsm

Behaviour

To declare your module as a behaviour callback module you include the -behaviour attribute.

-behaviour(gen_fsm).

Note: All this really does is to enable compilation time checking that
you have exported the required callbacks.

Exports

A module which uses the gen_fsm behaviour must export the callbacks which the gen_fsm module calls to handle events. These include handlers for common gen_fsm events as well as the handlers for your user defined states.

Startup

To start a process implemented in a module as a gen_fsm behaviour you may call gen_fsm:start/3. In response this function will call the init/1 callback in your module. After your init/1 function returns a result gen_fsm:start_link/3 will return the appropriate result to the calling process. Normally the result is to create a new process where the gen_fsm module is running it's internal main loop function waiting for messages to arrive.

2> {ok, FSM} = gen_fsm:start(simple_fsm, [], []).
{ok,<0.36.0>}

Events

To send an event to your finite state machine process you may call gen_fsm:send_event/2.

2> gen_fsm:send_event(FSM, foo).
ok

The result is that a message is sent to your FSM process tagged so that the gen_fsm module may recognize it as a gen_fsm generated event. When the main loop function in gen_fsm receives this message it will call the state handler callback in your module corresponding to the current state the FSM process is in.

An Example FSM

The Module

Below is a very simple example of a module implemented with a gen_fsm behaviour. In this module we will implement just one state and the only thing it will really do is to be chatty about what is going on.

Creating a New Behaviour

A Chatty FSM Behaviour

Now we may decide that a chatty FSM is a useful thing in a very general way. If we want to make other FSMs chatty we can put this functionality into a behaviour which our FSM modules may behave to. The basic idea is that we will implement the callbacks which the gen_fsm module will call as pass through functions to the callbacks in the user's module. These pass through functions will simply perform the chattyness and then call the FSM module's identical callbacks.

The Module

Note:

It is not suggested that this module performs a useful purpose as it is.
There are better solutions to add event tracing including passing the
gen_fsm start function the {debug, [trace]} option. The intent is to
demonstrate an enhanced behaviour.

You could write a simliar behaviour to do much more interesting things.

Conclusion

Cascading Behaviours

It has been shown that behaviour callback modules may also be behaviour modules. You may create a chain of callbacks of indefinite length.

An interesting example would be a complex finite state machine implemented in several behaviour modules such that the outermost had only a few states. Some of these states might be implemented as FSMs in inner behaviour modules.