Re: Applets and ThreadGroups (Was: Re: ThreadDeath - How spooky is that!)
Hi Oxide,
"Oxide Scrubber" <jharriman@hatlop.de> wrote in message
news:h4pcsf$tgh$1@aioe.org...
Richard Maher wrote:
Now, I had hoped that the Thread in question was just another
class-variable
but I can understand the concerns and the restriction.
What about accessing that Thread indirectly, via a static method like
public static Thread getTheThread () {
if (!theThread.isAlive())
theThread = new Thread(theRunnable);
return theThread;
}
That will return the existing thread, if it is still alive, and if it
has been killed it will replace it.
It's a bit more complicated in that the first thread is more than likely
stuck reading the socket. I don't want to close the socket, and the server
won't send anything until it's asked to. So the new Applet reader must
wait/join the old/reader in anticipation of the web-page/JS calling send()
which will generate a response which will finally let ThreadDeath in with
his scythe and tell the thread to die (or work out how many bytes you've got
left to read, put it where the other thread can find it, and then die)
The big issue is SUN's decree that the original Thread is irrecoverably
damaged and must die. (If that's more like "guidelines" and the Pirate Code
then let me know :-)
So if the user closes that last tab,
and then later reopens one, a new thread will be created.
That's the plan. It's just the old thread's socket-inspired, monty
python-eaque, unwillingness to die that is the fly in the ointment: -
1) Must leave the Socket empty or at a message boundry
2) Must not read messages destined for the new readerThread
3) Doesn't matter if the new reader get's old/out-of-date messages for which
there is no matching target window/tab
4) The good news is that we'll only get one ThreadDeath even though it can
occur anywhere
Any important state that was in the Thread object and should be
preserved will have to be moved to the (hypothetical) theRunnable or
some other object. But that's about it.
The problem is the "undefined" state of the readerThread after a ThreadStop.
To be honest, in initial testing, just trapping ThreadDeath and soldiering
on *appeared* to work like a charm but when the doc says that any monitor
locks are zapped and all sorts of other advice/frighteners then it's best to
replace it. (Yes with NIO I imagine that in the destroy() method of the last
Applet instance I could cancel any pending read and then gracefully end the
thread before the JVM but I'm still without a useful cancel_socket_read()
example and even then I think the thread/message-boundry clean-up will be as
cumbersome?)
Regards Richard Maher