Closed Bug 55004 Opened 24 years ago Closed 24 years ago

Webclient bookmarks don't work with tip.

Categories

(Core Graveyard :: Java APIs to WebShell, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: edburns, Assigned: edburns)

Details

Attachments

(3 files)

Webclient bookmarks don't work with tip.
a
Status: NEW → ASSIGNED
Attached file Checkpoint 10/2/00
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.
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:

M classes_spec/org/mozilla/webclient/test/EMWindow.java
M classes_spec/org/mozilla/webclient/wrapper_native/BookmarkEntryImpl.java
M classes_spec/org/mozilla/webclient/wrapper_native/BookmarksImpl.java
M classes_spec/org/mozilla/webclient/wrapper_native/NativeEventThread.java
M classes_spec/org/mozilla/webclient/wrapper_native/RDFEnumeration.java
M classes_spec/org/mozilla/webclient/wrapper_native/RDFTreeNode.java
M src_moz/BookmarksImpl.cpp
M src_moz/RDFEnumeration.cpp
M src_moz/RDFTreeNode.cpp
M src_moz/nsActions.cpp
M src_moz/nsActions.h
M src_moz/motif/NativeLoaderStub.cpp
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.

Thanks,

Ed
OS: other → All
Hardware: PC → All
Fix checked into the trunk.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: