archaelus

I'm going to try tracking the Erlang/OTP source tree and the helpful posts on erlang-patches in my git repository. I already have to do this for macports - odbc still doesn't really build out of the box on Mac OS - and the main configure script needs a few --with-gd=/Library/DarwinPorts arguments for my idiosyncratic macports installation.

I also have a few odd patchsets, such as Ulf Wiger's gproc - an extended process registry for OTP systems that I hope will one day be included in the standard distribution.

Maybe I could add the EEPs as branches too.

I’ve been writing Erlang code for a little while now and generally stick to OTP style systems. I find that I have a subconcious set of rules for deciding what kind of process to build for particular tasks - below are some of the guidelines I’ve come up with. This list is incomplete and I’d greatly appreciate feedback on it.

Signs you should write a gen_fsm:
* Your process responds to the same message in (radically?) different ways depending on the current state.
* You need to manage a collection of timers that depend on what state the process is in.

Signs you should write a gen_server:
* Your process always reponds to the same message in the same way.
* You mainly do a request-reply (call) style operations
* You're going to give the process a registered name.
* Your process is not going to trap exits
* Your process will be long lived
* Your process will be started by a supervisor

Signs you should write a gen_event:
* You want to modify SASL log handling.
* ???

Signs you should write a plain old process:
* You don't listen for requests from other processes (except perhaps replies)
* You don't fit neatly into any of the other boxes
* You are a worker process that makes blocking requests to other processes
* The rules for starting or restarting the process are complicated.
* The process does a number of different activities during its lifetime