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

[Matt Chatterley]

On Tue, 24 Mar 1998, Vadim Tkachenko wrote:
> Matt Chatterley wrote:
> > 
> > On Sun, 22 Mar 1998, Chris Gray wrote:
> > > [Ben Greear:]

[Snip]

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

What a shocker. My opinions (and an attempt to tickle this back to full
mud relevancy):
 
> 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.

1.0.2 is very out of date, though (and in general was buggy). You should
be using at least 1.1.3v2 nowadays, 1.1.5 or JFC (I think thats the name
for 1.2) even. I don't really suggest 1.2X, since its very new, likely
very buggy too - quite a bit changed/developed.
 
> 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.

Blech. The only browser I trust for proper Java compliance is HotJava.
Netscape 3.X needs patching to work at all properly, I think - and
Netscape 4.X is just bloated.
 
> JDK 1.2: Thread.stop() is deprecated - and let it rest in peace,
> Thread.interrupt() is quite enough.

Hmm. So threads truly are never destroyed by stop - really just stopped
and left useless? If so, interrupt() is certainly a better method. :) This
is something Java-in-a-Nutshell is not explicitly clear on.

This reminds me that I really must neaten up Spod! so that it interupts
its threads and makes sure to release all memory when internally closing
down bits of itself.
 
> > 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();
> }

This is more or less what I meant by 'suspend' (probably a poor choice of
words, really). I was looking at things from a theory rather than code
point of view, though.
 
[Snip]

While upon the notion of Java I'll toss an idea into the pit.

Java plug-ins for a client, which the mud can send.

Example:

PennMUSH uses an abominable system for mail (@mail
recepient=subject/message<enter>). How about if the server could aim you
to an URL containing a plug-in (I'm loathe to call it applet, it may not
work quite that way!), which gives you a small gui. A line for
receipient(s), a line for subject, a small editor box for your message and
a 'send' button which will send the command to the mud.

Not a great example, but a reasonable one.

--
Regards,
	-Matt Chatterley
Spod: http://user.super.net.uk/~neddy/spod/spod.html