[MUD-Dev] Event handling - some definitions

[Jon A. Lambert]

On 12 Jan 98 at 7:43, s001gmu at nova.wright.edu wrote:
> On Sun, 11 Jan 1998, JC Lawrence wrote:
> 
> > On Fri, 9 Jan 1998 15:00:37 PST8PDT 
> > Vadim Tkachenko<vadimt at 4cs.com> wrote:
> > 
> > > But once again, I emphasize, the difference is between treating
> > > everything as EVENTS and PROCESSES.
> > 
> > Note: "event" is actually a very poor term for what we are describing
> > here.  They really aren't events, but I'm unsure of a better name for
> > them.  
> 
> Actions?   
> 

Just thought I'd re-edit and repost this from the May archive:

----------------------------------------------------------------------

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 systems are hybrids of 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 - 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 - takes advantage of SMP, parallel processing or multi-threading.
C - even more difficult to implement with conventional languages  
    because data consistency problems, code/data locking and race     
    conditions need to be handled. 
P - extremely modular and strong susbsytem separation.

cf. primarily from "Object-Oriented Modeling & Design" - Rumbaugh, Blaha,
Premerlani, Eddy and Lorensen and "Rapid System Development" - Gane

-------------------------------------------------------------------- 
--
Jon A. Lambert
"Everything that deceives may be said to enchant" - Plato