OTP behaviours from Joe Armstrong's thesis
Wed Apr 19 17:09:07 BST 2006
- "let it crash", only write code to respond to messages that you expect, not catch-all clauses. It is best that the module crashes as soon and a noisily as possible if something unexpected happens, and in an OTP application it will be restarted anyway.
- gen_event responds to streams of events, doesn't necessarily reply to the process sending the event to the handler
- "The application is built bottom up starting with the worker nodes"
- gen_events are used for applications such as error logging, alarm handling, debugging and equipment management (p138)
- gen_fsm can be modelled as a set of rules of the form State x Event -> Action x State'
- supervisors are "meta-behaviours" that are used to glue the primitive behaviours into a supervision tree
- behaviours use callback modules that must implement a number of predefined functions for each behaviour eg handlecall for a genserver, handleevent for a genfsm. In contrast, applications don't implement callback functions but they instead rely on a specific directory structure and application specification file (.app file)
- there are a number of applications in /usr/local/lib/erlang/lib,
find the actual applications using
find /usr/local/lib/erlang/lib -name "*.app" (these are useful as examples) - grepping for the various behaviours shows a lot of genservers, fewer supervisors, only a couple of genevent (all for logging) and no gen_fsm in the standard included applications
- there are five behaviours used in OTP (including application), and 75 modules in the stdlib as of R10
- ets (Erlang term store) is useful on some occasions
- interior nodes of the supervision tree are supervisors, terminal nodes are gen_{server, fsm, event}
- analysis of the AXD301 switch revealed a flat tree structure, not deep. This is because "cascading restarts do not work".
- there is also a supervisorbridge behaviour (found by grepping for behaviourinfo in the stdlib src). A behaviour module for implementing a supervisor_bridge, a process which connects a subsystem not designed according to the OTP design principles to a supervision tree.
[erlang]
[permlink]