[MUD-Dev] World Persistence, flat files v/s DB v/s ??

[Vadim Tkachenko]

Matt Chatterley wrote:
> 
> 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. :)

Surprisingly, they are :-))

Some things worth mentioning:

JDK 1.0.2: Thread.interrupt() doesn't work. Thread.stop() doesn't work
as expected if called from within the thread you want to stop.

Netscape Enterprise 3.* JVM: the same. BEWARE: it advertises itself as
JDK 1.1 compliant, but in fact hopelessly broken - apparently, these are
not the only things which don't work - my package which had been tested
on JDK 1.0.2 from different vendors for almost two years choke and died
at once.

JDK 1.2: Thread.stop() is deprecated - and let it rest in peace,
Thread.interrupt() is quite enough.

> 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. :)

I wouldn't recommend messing with stopping and resuming threads, though
:-)

The better solution will be probably if you have some Thread-derived
class which works like this:

while ( isEnabled() )
{
 Runnable
	r = waitForRunRequest();	// blocking wait
 r.run();
}

Of course, this is an extremely simplified scenario, which, BTW, fits
into the ChannelSwitcher concept I described in the previous message.

>         -Matt Chatterley

--
Still alive and smile stays on,
Vadim Tkachenko <vt at freehold.crocodile.org>
--
UNIX _is_ user friendly, he's just very picky about who his friends are