[MUD-Dev] Event handling (was: request for comments)

[Vadim Tkachenko]

s001gmu at nova.wright.edu wrote:
> 
> On Thu, 8 Jan 1998, Vadim Tkachenko wrote:
> 
> > s001gmu at nova.wright.edu wrote:
> > >
> > > On Mon, 5 Jan 1998, Vadim Tkachenko wrote:
> > > >
> > > >Jon A. Lambert wrote:
> > >
> > > ...
> > >
> > > >>  Variations on event-driven design
> > > >
> > > >Can you please elaborate on that?
> > >

[skipped]

> > - One thread per connection listener (it's possible to install more than
> > one protocol adaptor, and therefore, connection listener)
> > - One thread per incoming connection
> 
> so... at least 2 threads per user?

Of course not - connection listener thread just accept()s the incoming
connections and
spawns the controlling thread

> The decision to go with ticks and a limited number of threads to handle
> the events for a tick stems directly from concerns of system load.  I
> don't want to design a game that _requires_ it be the only significant
> process running on a server. 

Well, I look at it from slightly different point of view - 

- my MUD project is for fun, but this is a guinea pig for every new
idea/concept/technique
- If I would write that seriously, the commercial application is a
target, then why wouldn't I dedicate the computer to run it?

A while ago (in 1992), I heard a joke which bottomline was - "any
mention about the performance UNIX geeks consider obscene". Well, I
laughed, but then, when I came to UNIX, I understood the pun - "if it's
slow, put it in background and forget about it until it's done".

> > Well, a while ago I've been told to implement a Web crawler for a site,
> > and the first thought was - just to go to the root URL, read and parse
> > it and as links appear, spawn other threads using the same algorithm.
> >
> > Obviously, you can parse the HTTP stream much faster than server
> > produces it, and, well, www.best.com (a guinea pig for that task)
> > started to fail when, say, something like 50th request thread was
> > started. Funny, but on my side (Linux, JDK 1.02) nothing bad happened.
> 
> As I said, it's very much a result of a lot of factors, including, but not
> limited to cpu speed, threads implementation, compiler, OS, the DB in
> use... etc.

Aha, and I also forgot to think that I was not the only user on the site
at that time, so effectively fail-threshold lies above 50.

> I am unfamiliar with the minSpare/maxSpare management strategy... the
> O'reily PThreads book didn't discuss it, and as that's the only book I
> really have avail... :)  Care to give a brief tutorial, or point me to a
> web page?  I am a tinkerer at heart, and would prefer an algorithm/design
> strategy to source code, as I prefer to code my own stuff.  :)

And I've never heard about PThreads book... See, all my knowledge is 99%
experience-based - you know, when O'Reilly book eats out 50% of your
monthly income (which was true until recently for me), guess what...

OK, so the minSpare/maxSpare strategy is what I saw in Apache HTTPD
(http://www.apache.org).

- You keep at least minSpare spare request handlers, just in case, so
first minSpare incoming
requests arriving simultaneously will be served really fast.
- After some requests are finished, you keep at most maxSpare spare
request handlers, terminating anything extra (variation: after they
expire by themselves).

That's basically it. Also, the implied consideration is you have to have
maxRunning request handlers and never exceed the limit or you're likely
to hit the system limits - just couple of examples:

- Artificial limit on evaluation versions of JDBC implementations
- MAX_THREAD

Also, you may consider dynamically change minSpare, maxSpare and
maxRunning depending on other conditions.

Also, there are two types of requests worth mentioning:

- packet request
- channel request

> mmm.. even in an asynchronous event handler, you can get two events
> targetting the same data executing at 'the same time'.  This requires
> either a lockless/rollback method or a data locking method.

Well, there are known methods to resolve this - either mutex semaphores
or synchronized methods in Java (btw, the absense of semaphores in Java
was really annoying, so I recreated them :-)

> Well, when you come down to it, even a so-called asynchronous model is
> still time-slice or tick-based.  the system's clock just has a very fine
> grain.  I suppose it's a throw-back to paper RPGs.  I played a lot of them
> for many years (really haven't played much the past couple... *sigh*), and
> it's hard to break out of the mold they establish.

Yeah, it was different for me - with my computer experience with games
which didn't engage turns (at least, obviously), like Eye of Beholder,
Ultima Underworld, I had no prejudice

> but when I tell my
> character to "cast fireball at bubba", it becomes trivial to implement the
> delay inherent to the action by scheduling the event to go off 3 ticks
> down the road.

By the way, this is exactly the point where extra threads appear in my
model. Every time-based action is asynchronously handled by the separate
thread, which allows to handle effects like spell backfires,
concentration, partial force release, accumulation rules, side effects
with extreme ease.

> yes, you could just as easily let bubba's character wait for however long
> and then generate a 'fireball is cast at bubba from boffo' event, to be
> handled immediately.  Either way works.  It's just a matter of where you
> choose to do your time and potential interrupt handeling.

See, I do not consider 'cast fireball' as EVENT. I consider it as a
PROCESS.

> > Let me point out one possible common target: if you use the concept of
> > context, or environment, and it's not a fixed value, then ...
> >
> > Like, time, weather in the area, gravity, etc.
> 
> mmm.. definately something to consider.  Thanks.  Anything else I missed,
> anyone?  ;)

Just an idea: lycanthrops, whose properties change with a phase of the
moon[s]

> > Two options:
> >
> > - save the event list and process it on the startup
> > - process all the list on shutdown. But, this situation may be more
> > difficult because events being processed may produce some more effects
> > and so on - for example, if you shout (RL) and then try to 'process the
> > event while shutting down', you're likely to:
> >
> > - Hear the echoes,
> > - Which may, in turn, cause the avalanche,
> > - Which may, in turn, kill a lot of people around,
> > - Which, in turn, creates a LOT of other events to process,
> > - and so on.
> 
> *nod*  good point.  I just realized that one of the other things we
> planned to do would work nicely with saving events and processing them at
> re-start...  We planned on setting it up so that if you logout outside of
> an inn or other "long-term storage" type safe-room, your character just
> sits there...  so, in the event of a... less than expected shutdown, all
> events are saved, all characters out and about are saved as such.  reboot,
> all characters are put back, and all events are reloaded.  Rather nicely
> takes care of problems like "cast fireball boffo" being reloaded with
> neither the caster or the target being around. I can see players being
> unhappy with the way things would work out, though.  It might be better
> to just let the events die.

Bad thing for me, because I'll have a lot of asynchronous events for
each object - for example, I'm going to implement the algorithm of
applying the temporary changes, illustrated by example:

- You get hit by the poisoned sword.
- Consequently, there are two state changes: your limb gets a wound
(let's make it a light one), and you get poisoned.
- Wound is going to heal by itself, slowly (asynchronous process, which,
in according to the abovementioned flexibility, may have variable rate
depending on your state, weather, nutrition etc.)
- Poison is going to continue to affect you (asynchronous process), once
again, with variable rate as above.

In other words, I'm not going to save only the event queue, but also the
[logical] process context, too.

> -Greg

PS: Once again, everything mentioned here is elaborated on
http://vadimt.4cs.com/~vt/gradient, the particular example with a wound
is described under 'Wounds' section, generalized as property modifier.
--
Still alive and smile stays on,
Vadim Tkachenko <VadimT at 4CS.Com>
--
UNIX _is_ user friendly, he's just very picky about who his friends are