Multi-threaded mudding (was a flamefest)

[Jon A. Lambert]

<By request, a x-post of mine from rgma >
:Flamebits and some minor editing done :-)

Event Modeling:
* An event is something that happens at a point in time.  
* An event has no duration.
* Two events may be said to precede or follow another or may be 
   unrelated.
* Those that are unrelated are said to be concurrent.
* An event is a one way transmission of information from one
   object/subsystem to another object/subsystem.
* It is not like a subroutine, thus there is no return.  An object/subsystem
   may expect a reply, but this reply would be in the form of an event under
   control of the second object/subsystem.
* Objects/subsystems are considered to be concurrent.

Event-driven systems:
* Control resides within a dispatcher/monitor provided by the 
   language/subsystem/OS.
* Procedures are attached to events and are called by the dispatcher when 
   the event occurs.
* All event procedures return control to the dispatcher.  They never 
   retain control.
* Program state cannot be preserved using the program counter and stack
   because procedures return control to the dispatcher.
* Procedures must use global variables to maintain state or the dispatcher 
   must maintain local state for them.
* Event-driven systems simulate cooperating processes within a single
   multi-threaded task. (multi-threading can also be simulated within
   the dispatcher/monitor BTW)
* A good example of such a system would be Sun View.

Concurrent Systems:
* Control resides in several independent objects/subsystems.
* Events are implemented directly as one-way messages.
* A task can wait for input, but other tasks continue execution.
* The operating system "usually" provides the queuing mechanism.
* Unix is a concurrent system.  Ada supports concurrent tasking.

Procedure-driven Systems:
* Control resides within the procedural code.
* Procedures issue requests for input and then wait for it.  When input
   arrives control resumes within the procedure that made the request.
* An operation corresponds to a pair of events.  An input event and
   an output event. {Usually implemented with call (values,...) and 
   return (values,...) }
* Gadzillions of programs are like this.

Many systems have subsystems which exhibit one or more of the above.

Some (P)ros and (C)ons-

Procedural Systems
P - very easy to implement with conventional languages
C - requires concurrency inherent in objects to be mapped into a 
     sequential flow of control.
C - asynchronous input cannot be easily accommodated.
C - flexible user-interfaces are hard to build.

Event Systems
C - more difficult to implement with standard languages.
P - more modular and handle error conditions better.
C - an errant procedure can block the entire application so
      good design is critical.
P - flexible control patterns can be simulated.

Concurrent Systems
P - 
C - 
Any thoughts about these?  I have just started exploring the area.

I believe whether you use OS-supplied threading or your 
application simulates threading makes no difference.
I do believe that is essential to at least simulate this
your mud world to be considered "event-driven".  

Second thoughts about above: Your platform largely determines 
what you should use, speed is likely an issue. 

Is this important to modeling a virtual world?  I believe it
is an important concept that will allow muds to evolve in
areas they haven't before.  Areas like AI, genetic, political,
and economic systems, better user interfaces, and more.
Sure many imps can say "been there, done that".  But have you 
really "done it" or simply forced it to fit within the "flatness"
of a sequential model.


Note:  Much of this was freely quoted from Blaha, Booch, 
Rumbaugh and Gane (and likely mangled by me).  

Any additions/corrections/clarifications are welcome.

A interesting doubt crosses my mine.
Should I be using ADA or something similar?  

JL

Some are born to sweet delight, some are born to endless night