[Home] [Groups] - Message: [Prev in Group] [Next in Group]
9453: [MUD-Dev] Re: Java I/O and threads.
[Full Header] [Plain Text]
From: Jo Dillon <emily@thelonious.new.ox.ac.uk>
Newsgroups: nu.kanga.list.mud-dev
Date: Mon, 25 Jan 1999 17:19:27 +0000
References: [1]
Organization: Kanga.Nu
Elis Pomales (pomales@caip.rutgers.edu) spake thusly:
> The current dilemma, is whether I should use threads on a per player (per
> socket) basis, or implement a polling loop and queue player commands,
> handling one command per player per loop cycle. The problem with having a
> thread per player is the context switching overhead. The problem with the
> polling loop is that I have to check each player to see if they have
> input. (There is no select() in Java.) Furthermore, processing one command
> per player may make the system very unresponsive??? Making it seem turn
> based?
I believe there's no non-blocking I/O either, so as you've foreseen
it wouldn't be a good plan. It could leave the mud locked up indefinitely,
in fact ;) With Java your best bet is one thread per socket, I should think.
> What solutions have you guys (and gals?) employed in your servers?
> I guess one way to use the polling loop would be to keep each command as
> small as possible...
>
> PS. I would still use more threads, one for NPC's and one for the game
> world.
>
> PSS. Is having 100+ threads really that bad? (I would think so)
Not necessarily - it depends on your hardware and OS. Java's designed
to use lots of threads so it's not too much of a worry.
--
Jo