[MUD-Dev] Re: Multi-threaded mudding (was a flamefest)

[Jeff Kesselman]

At 08:16 AM 5/3/97 PST8PDT, you wrote: 

>>>>

<excerpt>

<bigger>This application relies on the OS to generate all its events.

More particularly the socket port and the system clock.

All applications that run on a Unix machine would then 

classify as event driven taken collectively together as

a system.  Clearly not the intent of the distinction between

procedural and event driven.

</bigger></excerpt><<<<<<<<


::sigh::


Okay. First off COld does NOt generate these events off the OS. In point
of fact cold has an inetrnal processing loop that polls the various OS
sources and 

converts the results to events as needed BUT this is an implementatio
ndetail and totally irellevent.


The definition of event driven code is really very specuific, precise,
and has ntohing whatsoever to do with OS v. Application.


The MacInstosh and Amiga are 2 classic systems that program i nan event
driven model (Windows is a third, though overly complex and thus a bad
example case.)


The fundemental difference between the two models is that a standrad
procedural program queries for input and blocks until it recieves it,
then movign on. In thsic ase the flow of control is driven by the
procvedural code.


In contrast an event driven program registers a set of call-backs on
various input events with a central dispartch mechanism (be that OS OR
application code).  Code is then dispatched as the central loop senses
input events ocurring. In this model the flow oc tronl is dribven by the
suer events, thus the term "event driven."


At Philips we built a totally event driven system for CD-I development
that was ALL application code as a set of libraries.  


This is the definition of the term. IMO if this is not what you are
talking about you probably need to coin a new term rather then
over-loading an old one.


Jeff Kesselman