coder at ibm.net
coder at ibm.net
Sun Apr 6 09:27:57 New Zealand Standard Time 1997
On 03/04/97 at 03:49 PM, Michael Hohensee <michael at sparta.mainstream.net>
>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
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
...I take an explicitily multi-threaded event driven approach. To
describe: (please excuse typo's. I have the flu, and my eyes are
The server itself knows nothing about the game it is representing. It
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
The server is entirely event driven.
Every event executes asynchronously in its own thread using a lockless
The server core consists of the following base units:
The Dispatchor consists of two threads which own and operate the Event
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
One thread in the dispatchor handles placement of new entries onto the
Event List. The other thread processes the list looking for "ripe"
(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
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
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.
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