Regarding my musing on mdisp; Shawn's response is very reasonable in the
context of mdisp.
That context, however, is just what I want to avoid.
For mdisp, Ulf says "the threads themselves believe they stay up
I want to go one step further: the entities in question themselves aren't
even aware if they're threads or not (!)
I've decided to call the entities in question 'goats'. This is because
goats are cute, and they have square pupils. (In other words - there is
no good reason - at this point 'goat' is no less accurate than 'object' or
'thread' or 'dispatcher' would be.)
Clearly one of the main reasons Ulf wrote mdisp was for performance
(packing more processes into the runtime than would otherwise fit,
leveraging ETS when it scales better than processes, etc;) for me, that's
just a bonus. The main reason I'm writing a framework for 'goats' is
because I want to see what it is like coding in a style which abstracts
away as much of the difference between (dynamic) servers and (static)
structures as possible. I'm not even sure it's fair to say that goats are
concurrent at this point; probably better to say that goats are
Hope this clarifies some. If you want to see my code so far, I added
lib/ce/src/ce_goat.erl to Jungerl.
 the threads do react to an 'awaken' callback, so one could infer that
they are at least superficially aware that they were asleep.
>Clearly one of the main reasons Ulf wrote mdisp was for
>performance (packing more processes into the runtime than
>would otherwise fit, leveraging ETS when it scales better
>than processes, etc;)
True. Although I don't quite recall who wrote the first
incarnation of mdisp. It would be Peter Lundell or Mats
Cronqvist. It could well have been Kurt Jonsson, but I
recall him being on holiday at the time. (:
Ola Samuelsson originally (1996) wrote a multi_fsm(*) -- a
version of gen_fsm that handled lots of gen_fsm instances in
the same process. Mdisp was the successor of that model. We
did actually discuss the mdisp model already back then, but
for various odd reasons, we didn't get around to
actually trying it out until years later.
The mdisp model has proven better in at least one respect:
With multiple FSMs sharing the same process, all operations
must be non-blocking (or at least never block for long).
This led to asynchronous programming, which is very
difficult to handle.
Inventing ways to "raise the ceiling" was a higher priority
before OTP R9, since Erlang "only" supported 32,000
simultaneous processes. Now, with support for 262,000
processes, mdisp has lost some of its original
justification. It may still be useful for other reasons (or
in cases where roughly 200,000 simultaneous processes is
still not enough. ;)
(*) If memory serves me, Ola also wrote the gen_fsm
behaviour, as well as the original 'gs'.
Ulf Wiger, Senior Specialist,
/ / / Architecture & Design of Carrier-Class Software
/ / / Strategic Product & System Management
/ / / Ericsson AB, Connectivity and Control Nodes