Threads, IO handling, and Event Queues

[Carter T Shock]

> As for multi-threading, I would advocate understanding why you want to
> use it, before you devote much time to it. A program with multiple
> threads will run slower on a single-CPU computer than the equivalent
> program without threads. If you truly are targetting speedups by running
> on multiple CPU's, then fine. If not, then reorganizing your server into
> threads had better produce some real improvements in maintainability,
> etc., in order to offset the loss of speed.
> 

I agree that multi-threading is not an issue to be taken lightly. I'd
suggest that it only applies to the mud if you want to run different hunks
of your world asynchronously. You could run different regions as seperate
threads, unloading the threads when the region is devoid of players to
reduce load. You could also run with each user as a seperate thread, but I
wouldn't recommend it.

A shared memory solution has some interesting advantages over threads for
handling players and such. Sure, shared memory (and processes that
communicate via semaphores and such) is a cheap way to get threads. The
main advantage to using shared memory segments to hold the mud's data is
that you can attach any process to the memory segment. Consider:
	- you can develop admin tools that attach to the mud process but don't 	 
require you to log in as a "player"
	- you can develop "builder" clients that allow your build crew to attach
to 	  the mud and work, but don't allow interaction with the players (if
yer 	  gonna build, BUILD, if yer gonna play, PLAY.)

One of the things I like about SillyMUD is the catastrophe code. The goblin
raid on a town, the dwarf miner's revolt, etc. No reason you can't code up
these "events" as a seperate process that runs, attaches to the mud, loads
and tracks the appropriate critters, plays out its scenario and then cleans
up after itself. In essence, if you design well, you should be able to
dynamically modify what's going on in your world without having to reboot.