[MUD-Dev] Multi-threaded mud server.

[Travis S. Casey]

On Mon, 17 May 1999, Ross Nicoll wrote:
> On Sun, 16 May 1999, Caliban Tiresias Darklock wrote:

> Sorry, this is me not explaining what I meant very well, I think. As I
> understood it, most MUDs allocated a new thread per user. However, your
> later suggestions do seem definately better than mine...

As far as I know, most muds are single-threaded -- all LP servers that I
know of are, and I think most Dikus are as well.  Giving users threads
does seem to be something that a lot of new mud servers do, though.

> > If I'm correct in this understanding, and please correct me if I'm not,
> > then the "proper" way to implement such a scheme would be for each thread
> > to accomplish specific *tasks* instead of handling specific *objects*. So
> > instead of a series of "do things with an object" threads, you would have a
> > series of "do this thing" threads -- and those which are rarely if ever
> > called can be shut down entirely after a given period. For example, you
> > might have a "login" thread which handles everyone connected but not logged
> > in, a thread which handles combat, a thread which handles character
> > creation, etc. 
> An interesting idea, but I think it would require too much inter-process
> communication, and in particular may not load balance very well...

Hmm?  This would require *no* interprocess communication -- all the
threads are in the same process.  Load balancing between threads is only
an issue if you have multiple CPUs (otherwise they're all sharing the same
CPU anyways), and even then, it should be the OS's job to balance things
out (e.g., running multiple low-usage threads on one CPU, while a
high-usage thread might get its own CPU).

> > A related thought (and the one I'm still considering) would be a thread for
> > each area. When no one is in area X, that area can be safely unloaded from
> > memory; thus, with five players online, you don't need to have eighty areas
> > loaded. Just five, at most. All the other threads can be halted altogether. 
> Now this I like, as it kinda goes right around most of the database write
> problems... however, load balancing again becomes a problem, and player
> would have to be moved between threads, which is a problem in itself...

I'm not sure what you mean by "players would have to be moved between
threads."  Players aren't *in* a thread -- they're data structures which
belong to the process as a whole.  Different threads would access those
data structures, but that doesn't involve any "moving" of the data
structures.

>From what you're saying, it sounds like you might not completely
understand the difference between a thread and a process.  In a threaded
system, a process is the thing to which resources are granted -- thus, the
process owns memory, file handles, and things like that.  Multiple threads
exist inside a process, each executing a different part of the code that
the process owns.  Any thread within the process can make use of any
resource that the process controls -- thus, all the threads can access the
process' memory, file handles, etc.

No IPC has to take place, because there's only one process involved.
Threads may have to coordinate with each other, and IPC techniques may be
useful for that, but it's not IPC.  Thread communication can generally be
a lot more efficient than IPC can, since the threads can use the shared
resources of the process to communicate with each other.

--
       |\      _,,,---,,_        Travis S. Casey  <efindel at io.com>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-'
     '---''(_/--'  `-'\_) 



_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev