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

[Vadim Tkachenko]

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?
> 
> I've spent the last month or so of my free time tossing around ideas for our
> event driver, and I think I've finally settled on a general model.  I have yet
> to implement and test all of it, so I'm sure I'll be fine-tuning it, but here's
> where it stands for the moment:
> 
>   Definately Multi-threaded, though not as heavily as JC's model (so far).
>   I'm aiming for a statically sized pool of about 10 threads to handle events,
>   though that number is most certainly not set in stone.

Well, in my model there are no limit on the number of threads, usually
the number will consist of:

- Some small number of threads to wrap everything up (main server,
logger, console, etc.)
- One thread per connection listener (it's possible to install more than
one protocol adaptor, and therefore, connection listener)
- One thread per incoming connection
- N threads for db connections (implemented as a resource pool with
minSpare/maxSpare)
- As many threads as needed to implement some timed actions.

>   Pending events are stored in a queue wrapped in a pretty simple structure
>   containing a reference to the event object, an event ID, and the event's
>   timestamp (along with all the stuff necessary to make a doubly linked list).
>   Call it a Tuple if you like.

May I call it a Queue? This is a basic element in my model (as well as
everybody else's, I guess), but on the lower level.

>   Each 'tick', all events scheduled to be handled are pulled off the main
>   queue into a secondary queue, where the thread pool attacks them (in no
>   guaranteed order), each thread grabbing an event and calling it's Handle
>   method.  Threads go back to sleep once all events in the secondary queue
>   have been handled.

No ticks in my model - everything is completely asynchronous (though
synchronized). Each object takes care about itself, performing any
operations as soon as possible. The bottleneck is expected at the
database transaction (request? Sorry, I'm not as familiar with DBs as I
wish), so the abovementioned resource pool engages scheduling (some time
in the future I may think about PriorityQueue instead of simple Queue).

>   How many threads, executing potentially I/O intensive DB Queries, can run
>   simultaineously w/o bogging down the server?

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.

>   but for my sanity I decided on a static pool, with a boot-time configurable
>   number of threads. heck, I could prolly pretty easily add a command to
>   allow admin to add some threads to the pool on the fly, but I prefer to
>   minimize the cost of thread creation, localizing it to a boot-time expense.

I'd suggest to shift to minSpare/maxSpare thread management strategy.
Maybe, with some limit.
Once again, the source code is available :-)

>   For the lockless v. locked model, my main concern was/is how many threads,
>   executing at the same tick, are going to be handling events targeting the
>   same data?  I figgure there won't be too many events executed simultaineously
>   that target the same data.

Why bother? Change the event handling strategy to asynchronous.

BTW, question to all: Why the timeslice-, or tick-, -based event
handling model is still out there? See, I started to work seriously with
parallel tasks on OS/2, which is multithreaded by default, unlike UNIX
until lately, and I see no problems doing asynchronous event handling -
for 4 years now.

Why?

>  It will happen, there's no doubt about that, but
>   I feel the majority of events (executing at the same tick) will be aimed at
>   different targets.  This assumption may well be proven wrong, but for now I
>   can only go with it and see what happens.  :) 

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.

>  If it proves to be the case
>   that a large enough % of the events target the same data, I may adopt some
>   schemes to try and shuffle events targeting the same data into the same
>   threads, so they are executed sequentially by that thread, removing the
>   issue.

Then caching data makes a good sense.

>   I haven't spent much time on gracefull shut-down of the queue, or storing of
>   the event list to rebuild a queue, but they are next on the hit parade.

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.

> -Greg

--
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