[MUD-Dev] dispatching events

[Greg Miller]

Mark Gritter wrote:
> 
> On Thu, Jul 22, 1999 at 01:02:23AM -0500, Greg Miller wrote:
> I think the difference is mainly how much inconsitency you're willing to
> tolerate.  It doesn't seem to me that [3] preserves the semantics of [2].
> In particular, two events might appear in different orders to different
> objects.  This may not be a problem if your world allows this---

Your assessment seems dead-on. Further, there's no absolute guarantee
that all calls for one event will commit before calls are committed for
the next event. The question becomes "is that really a problem?" I lean
towards saying no--it seems to me subscribers should normally be
independent of each other, and thus not care about any of this. Hrm. Any
good examples of where people would tend to behave differently than I've
assumed?

> There are ways to a avoid pessimal behavior in [2].  For example, increase
> an event's "priority" each time it fails.  (J C Lawrence suggested
> something like this in the "lockless system -- foolproof?" thread last year.)

I vaguely recall that thread, I believe.

> 
> Another hybrid scheme is to break large subscriptions into atomic
> subsubscriptions of smaller size, grouped by "closeness".  The hope is that
> objects that interact with each other will see a consistent event model,
> while avoiding contention.  The bookkeeping necessary for this may tend
> to make it not worthwhile--- and there's little real gain in what semantics
> you may assume.

It really comes down to how often interactions among multiple
subscribers to the same event are useful. The problem is that I haven't
gotten very far into my mudlib, and thus have little experience with it.

> 
> Does [3] really have to be implemented at the driver level?  It seems
> identical in implementation to [1], except for the introduction of
> "subscription" objects.

No, it doesn't. I considered leaving it up to the lib, but I wanted to
hide all the event-handling mechanics inside the driver, and it had the
side benefit of allow more of a mix-and-match functionality: it should
allow me to provide, say, a mudlib and a web server as two
non-overlapping packages that can simply be compiled and left to run.
Both can simply subscribe to connection events and handle it if it's on
the proper port, ignoring each other completely. I didn't want to have
to provide a master object that handles events and dispatches to
different libs.

The downside, of course, is that event-handling can't be changed without
changing the driver, but I don't expect that to be a big deal.
--
http://www.classic-games.com/
Conspiracy theorists mistakenly assume others think before acting.
*** Please limit .sigs to four lines and avoid HTML mail or posts. ***



_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev