[MUD-Dev] Modular Design Issues RFC

[Scion Altera]

Thursday, February 15, 2001, 7:08:18 AM, Ryan Rhodes wrote:

RR> However, for some reason my instincts tell me that commercial games
RR> maintain a separate thread for each player.  This 'player' thread
RR> has it's own infinite loop and from it parses the players input,
RR> creates events, and executes them, thus simulating time for the
RR> player.

Not in Java on a unix machine they wouldn't.

My current project went through a stage where I had it set up just
like that. It was great because I could detect disconnects and block
for I/O without any trouble... and nobody else cared if your player
thread crashed.

However, keep in mind that every Java thread creates a new process in
unix. On a game with a high number of players, you would quickly find
yourself using up thousands of PIDs. I'm no expert, so I don't know
what effects that would have on a linux or solaris box, but I can't
imagine it would be pretty.

RR> The problems [individual player threads] would seem to create, in
RR> terms of data synchronization, would seem enormous.  If anyone has
RR> seen a system like this or has any input please post.

It wasn't so bad when I was fiddling with it, but I didn't do anything
even closely resembling stress testing on it. I imagine there were
problems lurking there that I never considered.

RR> An example of the benefits of such a system are thus.  After writing a
RR> new component online, our developers use the compile command to
RR> compile it.  To do a compilation we are going to have to block.  I
RR> could use a thread or thread pool to handle this type of action and
RR> have it send a notification to the players object when it is finished
RR> much like the manner you used threads for something in your post.  The
RR> problem with this is that to the player it appears as though he
RR> executed his command and is free to move about and execute other
RR> commands - like to clone this newly compiled file, only the file isn't
RR> really compiled yet and is going to let you know when it is.  Now had
RR> I just used the main game loop to block, the wizard would have felt a
RR> delay until the compile was finished, solving the problem.  The
RR> problem here, obviously, is that I've given everyone else a delay as
RR> well because I shut down the main game loop and everything that goes
RR> with it.  Now if every player had his own game loop I could just block
RR> his thread when he executes the compile command and everything is
RR> great.  I suspect this solution causes that wealth of synchronization
RR> problems I'm talking about.  Please comment.

I'm not entirely sure I follow you here.. but I gather you're wanting
to do something similar to a warmboot or copyover on smaug: developer
recompiles the code, types 'copyover' in the game, and the game
magically starts using the newly modified code without disconnecting
anyone, and ideally without even delaying anyone?

I haven't spent much time or energy figuring out how to do that for my
system, although it is most certainly a feature I would like to have.
My system is not split out into separate pieces.. so if I am going to
recompile I have to shut it down and restart the whole thing. I've
been considering a pretty wacky solution involving RMI, but haven't
gotten around to trying anything out yet. If anybody has any insight,
I would love to hear it :)

RR> Your point about Multi-processor machines being able to take advantage
RR> of multiple threads is correct.  I had forgotten this in my argument
RR> for threads.  I would point out though that java has already forced us
RR> to a separate thread for every connection, so in the context of that
RR> system I don't feel multiple threads handling events could do anything
RR> but degrade performance further.  With 99 connections and 1 thread for
RR> the game loop, a machine with 4 processors would already have 96
RR> threads in a wait state.  Our system aside, I really liked your idea
RR> of being able to configure the number of threads on a per system
RR> basis.

Ignoring my qualms about having 99 threads at all, I think it is
important to consider that none of the player threads should be
holding on to a processor for very long.. it seems like they would
read for input, fire off a single command (or perhaps an entire buffer
of commands), and be done. Unless your code is written very
inefficiently, I can't see those operations taking very long at all.
Each of the 99 threads should be able to get access to one of the 4
CPUs pretty quickly. (99 Java threads on the wall... 99 Java threads! 
*ducks*)

-- Scion

"Smoke a kipper for me, Skipper. I'll be home for breakfast." -- Ace Rimmer

-- keeler at teleport.com -- peter.keeler at brokat.com -- ICQ: 1824934 --


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