Advantages of a large number of threads cf other approaches?
Mon Feb 16 22:06:59 CET 2004
On 16 Feb 2004 at 19:32, Joe Armstrong wrote:
> > * Internet servers - why not use asynchronous sockets running in a
> > single thread?
> Because of errors.
> Think of the process as not only providing units of concurrency but
> also of providing error encapsulation boundaries.
> Erlang was designed for programming fault-tolerant systems - to do
> so we must make sure that faulty code running somewhere in the system
> does not crash good code - the process provides the error
> encapsulation boundaries. This is the single most important property
> that a process has.
This was pretty much what I very tentatively said. It's nice to have
someone who's opinion eans something tell me I've not made a
(tentative) idiot out of myself...
> > * Simulations - why use an object per thread rather than a "classic"
> > OO approach?
> This depends upon the simulation - if you are modeling the real
> world then mapping each concurrent object in the real world with
> exactly one concurrent processes bridges between the gap between the
> model and the simulation code in a very natural way - the code will
> almost "write itself".
I've heard this said before (and have read code samples etc) but I
keep feeling I'm missing something. It's so easy to have all your
objects inherit from a Smalltalk/C++ base class with an update method
and loop through all of them. Possibly I'm at the stage where I'm
over-adapted to OO and no longer notice some of the discomforts...
More information about the erlang-questions