Advantages of a large number of threads cf other approaches?

[Jay Nelson]

There was a discussion of processes last year.  I tried to
catalog a variety of uses for them.  See
http://www.erlang.org/ml-archive/erlang-questions/200303/msg00441.html

 > 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.

This works fine if they are all in lock-step.  If some are
expected to react  more quickly than others, you have
to modify the loop.  In the general case, your loop encodes
priority and other semantics that are more rightfully imposed
by the simulated objects rather than the simulation environment.

If the "messages" or "update triggers"
are unevenly distributed you have to deal with the problem
without blocking progress of other individuals.

If you want truly independent behavior and don't want to write an
asynchronous handler rather than a looper, you are better off
with an OS feature such as separate processes with a scheduler.

Looping will be faster, but in general not simpler to code (although
in the common case it will be familiar and straight-forward).
Using processes allows a much simpler separation of concerns
and the ability to scale to more processors at will (the real
proof of whether the simulation is truly concurrent or if
the simulated objects are independently modelled).  For simple
simulations you may never notice the difference between the two
approaches.

jay