Advantages of a large number of threads cf other approaches?

[Andrae Muys]

jonathan@REDACTED wrote:

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

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

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

-- 
  Andrae Muys    <andrae.muys@REDACTED>
  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