Webclient bookmarks don't work with tip.
Created attachment 16020 [details]
After looking at this long and hard, I have determined that I need some JDK
person to help me. I think it's thread related.
Created attachment 18474 [details] [diff] [review]
cvs diff -u of fix for this bug, first iteration.
Created attachment 18475 [details]
tar.gz of fix for this bug, first iteration. Untar onto 11/1/00 webclient tree, in the webclient directory.
This fix makes it so bookmarks work with the tip of the branch as of 11/01/00.
This fix removes the necessity to modify xpcom/base/nsDebug.cpp to
remove the thread safety assertions.
This fix primarily does two things:
1. Make nsActionEvents for all bookmarks/rdf actions
2. Remove the synchronized(this.browserControlCanvas.getTreeLock()) call
around nativeProcessEvents() in NativeEventThread.run().
Files in this fix:
Here is the reason for the deadlock:
Our NativeEventThread runs the pump that pulls events out of a queue and
processes them. The processing of these events happens inside a
synchronized(getTreeLock()) block. Events are put into this queue by
anyone that wants to send an nsActionEvent.
In order to not get the thread safety assertion for bookmarks, I had to
convert bookmarks over to use nsActionEvents for all calls to the
bookmarks or rdf service.
So, the NativeEventThread is humming along. We're inside a
getTreeLock() synchronized block.
Meanwhile, the AWT thread is trying to draw the tree. All of these
drawing calls happen inside of a getTreeLock() synchronized block.
Eventually our RDFTreeNode.isLeaf() is called. This call puts an
nsActionEvent in the queue and waits for it to be processed, but it
can't be processed because the AWT thread is blocked waiting to acquire
the tree lock!
My solution was to remove the call to getTreeLock from
NativeEventThread, but this has dire consequences on Solaris.
Anyone with another suggestion please volunteer it here.
Fix checked into the trunk.