[MUD-Dev] World Persistence, flat files v/s DB v/s ??
Matt Chatterley
matt at mpc.dyn.ml.org
Sun Mar 22 19:18:47 CET 1998
On Sun, 22 Mar 1998, Chris Gray wrote:
> [Ben Greear:]
[Snip]
> :Also, as a java server, I don't think I can do a select on incomming
> :data. I think a thread for every player is a bit much...any suggestions
> :here?
>
> I have just started into the socket programming stuff of the current Java
> book I'm reading, but I just went and did some scanning. The technique
> he suggests for a server is to create some fixed number of threads, and
> re-use those threads throughout the lifetime of the server. He says that
> some Java implementations do not garbage collect threads at all, so having
> one per connection can result in an eventual crash due to lack of memory.
> Ick. Given the lack of a 'select' or 'poll' method in Java, the choices
> are quite limited. Double ick.
It is my understanding that (at least, according to the 1.1.x
specifications), a Thread is terminated when its stop() method is called.
Of course, some Java implementations may be buggy. :)
Reusing threads is probably desirable, by the way, especially if less work
will be done to re-use an existant thread than to create a new one, and
not hard to do.
Consider a model where you have a resizeable array (see the Vector class)
of Threads. You also maintain a list of available threads so you do not
have to recalulate it, and follow a procedure akin to:
New connection is made to the server:
Check list of available threads.
If null: extend the Vector and add a new thread to handle the
connection.
If not null: take the 'top' thread and re-assign it.
A connection closes:
Add that thread to the list of available threads.
Suspend and 'reset' the thread.
Seems interesting anyway. :)
--
Regards,
-Matt Chatterley
Spod: http://user.super.net.uk/~neddy/spod/spod.html
More information about the mud-dev-archive
mailing list