Event-driven?

coder at ibm.net coder at ibm.net
Sun Apr 6 09:27:57 CEST 1997


On 03/04/97 at 03:49 PM, Michael Hohensee <michael at sparta.mainstream.net>
said:

>Precisely how does an event-driven mud work?  I understand the idea, but 
>I don't see how it could be run efficiently, and be coded neatly...

>Can somebody enlighten me?

Event driven eh?

  In the beginning there was nothing but an endless void without
dimension.
  And then there cam an event.
  And the event created a change.
  And then there was something.
  And nothing was ever the same again.

I'll presume that you understand the basic concepts of how an event driven
system works.  From there its probably easiest to detail how my system
approaches being an event driven system.  The following was wrtten a while
ago:

--<cut>--
...I take an explicitily multi-threaded event driven approach.  To
describe:  (please excuse typo's.  I have the flu, and my eyes are
burning)

  The server itself knows nothing about the game it is representing.  It
has
  no parser, game knowedge, or anything else application specific.  All it

  does is represent a database.

  The database consists of records.  Each record defines an object in the 
  MUD world.  An object may have attributes, methods, and verbs defined on

  it.

  The server is entirely event driven.

  Every event executes asynchronously in its own thread using a lockless 
  model.

  The server core consists of the following base units:
    -- DB
    -- Dispatchor
    -- Executor
    -- Connector

  The Dispatchor consists of two threads which own and operate the Event 
  List.  

  The Event list contains an entry for every event which has been logged 
  with the system but not processed yet.  Logged events are of two forms:
  1) execute at XXX time, or 2) Percentage chance of execution within
time.

  One thread in the dispatchor handles placement of new entries onto the 
  Event List.  The other thread processes the list looking for "ripe"
events 
  (ie ones ready to be executed).

  Ripe events are sent to the Executor where they are placed in an Event 
  Queue.  The Event Queue is a priority queue with events ordered by their

  own execution priority.

  The Executor manages the Event pool, a local pool of threads (the number

  dynamically grows and shrinks at runtime depending on load) which are
used 
  to execute the events pulled off the Event Queue.  Threads in the Event 
  Pool are re-used to execute ripe events.

  Events are pulled off the Event Queue in priority order and handed to
the 
  first available thread.  

  Compleated events can log futher/later events back to the Dispatchor for

  subsequent animation.  This is how mobiles are naimated for instance.
  
  User IO arrives thru the Connector.  The connector is essentially a 
  pool of threads which asynchronously manage the general pool of outside 
  connections.  A seperate monitor is responsible for keeping the IO 
  network tree happy.

  User commands arrive at the Connector and are immediately sent to the 
  Dispatchor as Execute-In-Zero-Time (ie no delay) events.  The event 
  logged is acutally to parse the command as entered.  The dispatchor 
  then routes the event to the Executor, it runs the event and the 
  resultant parse creates a new event which is logged with the Dispatchor 
  to actually execute the intended action.  
--<cut>--

What you may note in the above, is that there are no timing loops, pulses,
heartbeats, polling (gasp!) or similar.  They don't exist, and I don't
intend to let them exist.  For anything to happen it must log an event
with the Dispatchor.  The Dispatchor and the Executor then collude to
determine when exactly it will be executed.  If there are no ripe events
demanding current execution -- the server idles, and does nothing.  There
are no loops going on with the server running about in circles checking to
see if anything needs to be done, or updating status.  If there are no
currently ripe evnts, the server does very very literally NOTHING.  It
just sits there and blocks until an event ripens.

--
J C Lawrence                               Internet: claw at null.net
----------(*)                              Internet: coder at ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...





More information about the mud-dev-archive mailing list