[MUD-Dev] Thread Pools (was: Re: TECH: Distributed Muds)

[Matt Chatterley]

> From: Scion Altera <keeler at teleport.com>
> Reply-To: mud-dev at kanga.nu
> To: Matt Chatterley <mud-dev at kanga.nu>
> Subject: [MUD-Dev] Thread Pools (was: Re: TECH: Distributed Muds)
> Date: Thu, 24 May 2001 11:46:42 -0700

> Wednesday, May 23, 2001, 3:44:32 AM, Matt Chatterley wrote:

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

> Why do you need one thread per player? Why not just have one thread
> that iterates through the sockets and queues up their input and
> spits out their output buffers? As long as this thread doesn't block
> and isn't allowed to run wild (I'm running mine at one pulse per
> 1/8th second at the moment), it seems to run well enough.

It depends on how much data you pass back and forth, I guess. When
planning the system I've got on paper now, I worked to one thread per
player, probably because its conceptually simple. I was quite tempted
to devise a sort of 'internal virtual thread' system so that multiple
game threads would be run by one actual thread, then wondered if I
would actually save any work that way. :)

Under this logic, all of the player threads would be 'sub parts' of
the input processing thread.

If you want a truly real-time game, which scales to /lots/ of players,
one thread per socket makes more sense. Otherwise, I think you're
probably right (I might put more thought into my virtual threads,
actually).

> I'm thinking in terms of the hobby mud, of course, rather than a big
> fancy graphical MMORPG, and have yet to do any serious load testing
> on my game, mind you :)

I've never really done any load testing, I have to confess. Not
seriously. My last Mud project fell apart due to lack of time (on the
part of the entire, rather large development team), before we got to
that point - it was plagued by problems from the start (since it began
as a rewrite of an existing LP MudLib, and turned into the creation of
a new one from the ground up).

> Even so... one thread per player seems like overkill to me. Not only
> does it necessitate thread safety for all your code (thus
> introducing uncertainty and various sundry synchronization issues)
> but there is a substantial amount of overhead per thread that seems
> unnecessary.

Thinking about it again, it does seem excessive.

> Branching out from my own current model for a moment, and touching
> on something asnellin at san.rr.com mentioned in your quote, what about
> a thread pool?

[Snip threading model]

> This way if there are zero connections to the game, there are zero
> threads updating the connections. The number of threads vs. the
> number of connections is fuzzy, and varies based on the machine the
> program is running on. My p3 800 might be able to handle fewer
> threads vs.  connections, while my 486 may very well be up to the
> top limit in threads most of the time, trying to keep the update
> rate high enough.
 
> A good thing to do would be to make the top number of threads and
> the desired socket refresh rate to be tweakable numbers, so it could
> be optimized based on the capacity of the hardware.
 
> Now that I've actually worked the model out, I think I'm going to go
> implement it. Anybody see any glaring omissions/errors? :D

Sounds pretty good to me. :)

I might make another post today about events, now I think about it,
since its a topic I'll encounter soon in my programming efforts.

-Matt


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev