Bug 2: repaint() calls do not always result in update() calls:

Make sure your status bar is displayed, using the View menu.

The numbers should be changing. If they are not changing, the bug has already happenend. You can get them to change again by obscuring/revealing the Safari window. Sometimes it takes a few tries (hint: use Alt-tab).

Once the numbers are changing, click on the applet area and hold down the mouse button. If the numbers keep changing, try clicking again. If you cannot get them to stop changing after several clicks, try reloading the page. Update: In 1.0 Beta V.60, I cannot get them to stop changing with a single click. However, if you resize or scroll the window, the updates stop. Therefore, the bug is still present, but it is harder to reproduce in the latest version. Once they stop, observe the status bar. See that the numbers match the ones displayed by the applet. (If they do not match, get them spinning again, and then click again. Repeat this until you get a set of matching numbers.) The only way you can get matching numbers is if the mouse event was processed after the update finished, and before the execution thread had a chance to update the counter and request another repaint. Because of the rates I used, the probability is very high that you will get this result.

If you release the mouse button and press it again, the screen does not update, but the r= (repaint) value in the status bar has increased by one.

This means the repaint method was called, but that did not result in a call to update.

The reason obscuring/revealing the window breaks the deadlock is because the paint() method calls update() which fills in for the update() which never happened, thus releasing the semaphore variable, and letting the process work again.