Sun Mar 23 19:38:22 CET 2003
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.
More information about the erlang-questions