rcosjava-general — The list to get in touch and discuss RCOSjava.

[<And...@ne...>]

"Peggy Newman" <pe...@ip...> wrote:

>And if so, why is this necessary? Because I understand that the 
>start() method for the applet (and consequently 
>kernelThread.start()) is called *after* init() is finished. 
>
>I thought that maybe it's useful when a user leaves the RCOS.html 
>page (or maybe even the main applet screen?) and comes back to 
>it. But that can't be right, because start() is called when the user 
>returns, and not init() which contains startThread().  (Just a train of 
>thought.)
>

It goes init(), start(), run(), and stop().  init() does the basic
initialisation.  start() calls startThread() (from 
setupAnimatorLayouts()).  If startThread() is not called by start() 
then the running variable is always false.  So when it gets to run() 
the thread waits and is never notified.  When startThread() is called 
by the ProgramManager (from another thread) then it's notified and 
keeps running.  So if you comment out that call, go to "Program Manager"
and hit "Run" and it will work!

It was also done for minimize/maximize/entering/leaving/reloading 
pages.  This was done for largely historic reasons.  When RCOS.java was 
a 1.1 applet sitting in IE 3/4 and Netscape 3/4 the 
init/start/stop/destroy calls were called at different times for
different browser versions.

If you want information about it check out:
http://support.microsoft.com/support/kb/articles/Q227/2/10.ASP
http://developer.netscape.com/support/faqs/champions/java.html

In the end, you're probably wondering why I did it this way.  Me 
too.  I don't think this is the best way but I hate threads and 
it does work okay but it needs improvement (see below).

>Q. This 'running' variable - deemed volatile - I understand this to 
>mean that it might be changed from an external source ie another 
>thread. To compliment my other questions - when does 'running' 
>become false, aside from its initialisation?
>

This is just following Sun's documentation about "Why Thread.stop,
Thread.suspend and Runtime.runFinalizersOnExit is deprecated".

http://java.sun.com/products/jdk/1.2/docs/guide/misc/threadPrimitiveDeprecation.html

It's to "ensure prompt communication of the stop-request, the 
variable must be volatile (or access to the variable must be 
synchronized)."  The startThread() method is synchronized but 
the isRunning() is not.

In previous version there was this method:

public synchronized void stepThread()
{
  running = false;
  notify();
}

This was part of the implementation to step through an instruction
at a time.  The bug for this is here:

http://sourceforge.net/tracker/index.php?func=detail&aid=452014&group_id=5762&atid=105762

>
>Also, I see that the kernelThread loops around for its existence, 
>calling performInstructionExecutionCycle(). Why does the thread 
>then sleep?
>

This is just to allow other threads to run.  The animator thread 
gets pretty starved when the sleep is removed.


__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/