Advantages of a large number of threads cf other approaches?
Tue Feb 17 05:53:38 CET 2004
> On 16 Feb 2004 at 19:32, Joe Armstrong wrote:
>>>* Internet servers - why not use asynchronous sockets running in a
>> 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"
>> 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...
Hand-rolled co-operative multithreading. Been there, done that, no
thanks. Yes this approach works *if* you can guarantee that every
function called (directly or indirectly) from an update function is
non-blocking. This also presumes you have access to co-routines in your
language, or else everything becomes a state-machine whether you like it
So if you are programming in a language with reasonable support for
co-routines; support for return-from-calling-coroutine semantics; and a
non-blocking standard library (presumably using aformentioned
semantics); then you are sitting pretty. If not then you will have to
pay a rather high price for the dubious 'advantage' of not using a
pleasant language like erlang ;).
Andrae Muys <>
Engineer Braintree Communications
"Now, allowing captured continuations to be inspected and altered at
runtime (including binding mutation, complete rebinding of scopes,
and call tree mutation)... *that* is really evil. And, I should
point out, quite useful." - Dan Sugalski
More information about the erlang-questions