when to add a process [and plug for Erlang Workshop]

[Ulf Wiger (AL/EAB)]

One way to look at processes, that may seem simplistic at first, is:
- too few processes will complicate your state machine logic
- too many processes may add delays & overhead and/or complicate 
  your error handling

It is _very_ important to avoid multiplexing several state machine
instances in one process. Whatever you think you'll gain by doing
so, it is not worth it. I'm working on a tutorial to illustrate this.

A related point is: don't use the OTP behaviours gen_server or gen_fsm
for anything but very simple state machines (a stateless server is 
the simplest possible state machine ;-)

I agree with the verdict on the workshop. It was quite pleasant.

Richard Carlsson's talk on exception handling was very good,
explaining the pitfalls of the current exception handling in 
Erlang, and describing an upcoming framework that looks very
promising.

John Hughes gets bonus points for giving the obligatory type
checker talk, but succeeding in explaining why it is so 
difficult to design a static type checker for Erlang.  (:

Daniel Shutte keeps conquering the third world with Erlang.
I've never made the connection that banking and lotteries 
would be essentially the same thing. (: I hesitate to draw
the analogy any further...

/Uffe

> -----Original Message-----
> From: owner-erlang-questions@REDACTED
> [mailto:owner-erlang-questions@REDACTED]On Behalf Of Hal Snyder
> Sent: den 29 september 2004 17:21
> To: erlang-questions@REDACTED
> Subject: when to add a process [and plug for Erlang Workshop]
> 
> 
> This is a note to indicate how much I enjoyed the Erlang Workshop at
> Snowbird last week. It was great to meet Erlang experts, learn of new
> developments, and exchange ideas.
> 
> Just a few examples: HiPE on AMD64, Joe's EX11 GUI, a demo of the
> Dialyzer catching errors in Erlang code, and the SSH2 protocol in
> Erlang.
> 
> 
> Jay Nelson's talk, "Structured Programming Using Processes", made me
> wonder - when is it a good idea to create a new Erlang process?
> Here are a couple cases:
> 
> 1. Tracking state - any state machine, whether coded with the OTP
> behavior or not. Protocol drivers are classic examples. Another
> example is tracking which of several external redundant resources is
> to be used in a high availability setting. (Of course everything is an
> fsm at some level, but there is a practical principle here as well.)
> 
> 2. Serializing access to a resource.
> 
> 3. Monitoring an external Unix process (Erlang port).
>