[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