Design phase in Erlang

[martin j logan]

Eduardo,
    I think that one of the things that takes the longest to come to
grips with when learning erlang is that a process is EXTREMELY
lightweight. It takes only a scant few microseconds to spawn one. This
fact and a few others, efficient messaging and no shared data, make it
possible to really program with concurrency in mind. You should thus
endeavor to model your problems in erlang with processes as the primary
abstraction. The rule set forth by one of the "erlang guru's", I'm not
sure who, is one process per truly concurrent activity in your system.
By adhering this paradigm it is possible to elegantly reflect a problem
with your code. As always "make it work, make it beautiful, make it
fast(if you really have to)". So my advice in a nut-shell use a process
per client request because that seems to be the correct granularity for
modeling your problem. This will make your code infinitely more readable
and maintainable than a "preemptively fast" single process approach.
After doing so if you don't get the performance that you need, go ahead
and re-factor the code.

Cheers,
Martin  

On Fri, 2002-12-06 at 09:16, Inswitch Solutions - Erlang Evaluation
wrote:
> Erlang Devs,
> 
> I have a procces in machine M1 which receives requests to run a state machine which I called "service". 
> N clients send a request to machine M1 to execute the service.
> 
> From the Erlang point of view, is it a good design to have a process for each client request (N processes) ?
> 
> Viewing it from another way, the service has the same code (logic) for each client but different instances for each client (the states).
> Though, could be better to have those states for every client saved in some kind of structure and use the same code for every client by messages and recursion usage ( only 1 process) ?   N times reentrant code vs N processes.
> It'd be harder to implement but I don't know how Erlang manages the N processes (N same execution routines) in memory when a huge number of processes are running.
> 
> I'd greatly appreciate some feedback about this.
> 
> Thanks,
> Eduardo Figoli
> INswitch solutions
> 
> 
>