[MUD-Dev] request for comments (was: Mud-Dev FAQ)

[JC Lawrence]

On Thu, 8 Jan 1998 08:52:08 PST8PDT 
s001gmu <s001gmu at nova.wright.edu> wrote:

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

Notes: Thread creation is typically far cheaper than process
creation.  Threads can also be blocked.

I vary the thread pool size dynamically.  It grows under load, and
shrinks in time of extended drought.  

The system is a little more complex than this as there is a minimum
thread count for the Event Pool, and if traffic falls enough that some
threads in the Event Pool are left work-less I block them instead of
killing them.  Thus, if traffic loads later increas and those threads
would be useful again, I merely unblock them for them to get back in
the fray.  The expense?  A little increased swap image and possibly a
slightly increased scheduler load depending on your system's thread
model.  

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

Its a tough and nasty call.  The reason is that it is utterly load
dependant, and that is affected by the stylistic approaches of your
world coders, the activity characteristics of your players. etc etc
etc etc.  Suffice to say that I see the problem to a huge degree at
times (suddenly the rate at which events fail C&C goes thru the roof),
but its erratic, unpredictable, and often seems to be mollified by
ensure than events are as short as possible, and affect as few objects
as posssible.

>   What happens if it takes more than one tick to process all the
> events in the secondary queue?  This says either that there are not
> enough threads to process all the events quickly enough, or that
> there are too many events! :) I'm thinking I'll just put the events
> in the same secondary queue, and have the threads do a bit of
> prioritizing... only if there are no threads executing events for
> the previous tick will they start processing the new tick's
> events...  dunno.  I need to think about it some more.  :)

Depending on how hard a given attempted event execution is finding it
to C&C successfully, and depending on what its effrot setting is (how
hard it tries to succeed in the face of C&C failures (some events are
flagged that they must execute)), I will gradually degrade the server
down to single threaded just to allow a given event to compleat.

Performance during that degredation suffers of course.

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

I store all the relevent queses and lists are objects within the DB so
they are saved (and available for rollbacks) just as anything else
is.  Happily event queue and list objects are *really* small for my
disk space limits.

--
J C Lawrence                               Internet: claw at null.net
                                           Internet: coder at ibm.net
----------(*)                        Internet: jc.lawrence at sun.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...