[MUD-Dev] Re: TECH: Distributed Muds
mpchatty at hotmail.com
Wed May 23 10:44:32 New Zealand Standard Time 2001
>From: Daniel.Harman at barclayscapital.com
>> -----Original Message-----
>> From: asnellin at san.rr.com [mailto:asnellin at san.rr.com]
>> Actually, it's more like a constant number of threads per
>> connection, likely only one or two. But that's why I'm asking these
>> questions -- would N*2 threads kill a system, even if intelligently
>> managed? Even if 90% of them were blocking at any given point in
> That really wouldn't scale well on any OS that I'm aware of. You
> might want to consider a thread pool to which you allocate units of
> work as and when requests are received. To just add more and more
> threads in will lead to heartache and pain. Remember, the optimal
> number of threads is generally the number of CPUs in your system
> assuming that they aren't sat waiting on events doing no processing.
There was (I think) quite a lot of discussion on this list some time
about about Event Queues and so forth (more in term of a 'Event Driven
World Model' admittedly, but it still fits).
However, to my mind (I'm not very hot on multi-threading, or even
network aware programming, though), there are going to be a minimum
number of threads required by a Mud. Given a central event queue which
handles all actions and consequences (one thread), you will also need
at least one thread per player to read from their socket and forward
what they type to your processing layer.
A model which would work (hopefully) does occur to me.
[Socket connections] - 1 thread per player to read data and pass on
[Input processing layer] - 1 thread which interprets all player input
[Event Handler] - Accepts events from systems, orders and initiatves
actions, events, and consequences to keep the In-Character world
Some commands and actions defined as 'out of character' don't need to
be queued up (ie chatlines).
Hmm. My head hurts.
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev