Gen_server and multiple processes

martin j logan martin@REDACTED
Thu Dec 19 19:06:42 CET 2002


Einrich,
    The way that is typically advocated for dealing with concurrency is
one process for each truly concurrent activity in the system. It is the
task of the programmer to determine exactly what that means i.e the
proper granularity for modeling. Many things can be concurrent but are
they salient in terms of the overall architecture, could you easily give
each of these processes a name on a data flow diagram without an
explanation? Are they truly, logically concurrent? If not chances are
they really have no overwhelming need to be executed in a non-sequential
manner. Of course there are exceptions to this rule but on the whole it
stands.
Some of the general things I ask myself are:
- Is there a simple and logical linguistic formulation of my reasoning,
can I explain it easily? These things are separate processes/entities
because...
- Would I include this process in a Data Flow Diagram? Would it get a
name that is not an explanation? 
- If I implement this operation sequentially will I place a significant
bottle neck in my system?
- Does the concurrent implementation of this operation simplify the
overall architecture of my system? Does it make it more elegant? 

Getting a feel for thinking in terms of concurrency took me some time. A
good scenario to re-examine in these terms is the implementation of a
TCP server vs. a UDP server. It is easy to explain why a TCP server
should have a concurrent process per TCP stream. It simplifies the
overall architecture and avoids a potential bottle neck. There is a
clean logical separation between the truly concurrent elements, streams,
in this case. 
There exists no such easy explanation, salient logical separation, or
architectural simplification when talking about the UDP server.
Typically one would not implement a concurrent process for each UDP
connection i.e each packet. Further more implementing it sequentially
does not introduce a bottle neck into the system and would probably make
your overall architecture cleaner.

I hope that this helps - I would also like to hear if others agree or
have another way of looking at modeling concurrent systems.

Cheers,
Martin

On Thu, 2002-12-19 at 03:08, hfventer wrote:
> Hello all
> 
> I would like to know if the gen_server behavior creates a separate
> process for each message that is sent to it, or must this kind of thing
> still be written into your own code?
> In other words, if several calls to the function foo() is made, will
> there be several processes each running handle_call spawned, or will
> there be several queued calls to handle_call?
> It seems that playing to Erlangs strengths in this situation makes the
> most sense :)  Would spawning a process to handle foo and returning
> immediately might be the correct way to do this type of thing? (if
> gen_server does not do it already).
> 
> -]-[einrich
> 





More information about the erlang-questions mailing list