Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[platform-text-dev] Closing CDT editors delayed by reconciler synchronization

Folks,

  The CDT team is looking for some help/guidance on a behaviour that has
been
annoying our users for a couple of releases now.  The problem is that
closing
C/C++ source editors results in small delays that increase with the number
of
editors open (https://bugs.eclipse.org/bugs/show_bug.cgi?id=130089).

We have tracked this down to the synchronization that happens when the
dispose
listener (from the TextViewer) calls setDocument(null) before
handleDispose().  

This document change ripples through firing document change listeners one of
which is the listener attached by the AbstractReconciler.  In the method
(from
AbstractReconciler):

inputDocumentAboutToBeChanged(...) {
	...
	if(fIsIncrementalReconciler) {
		synchronized(fDirtyRegionQueue) {
			fDirtyRegionQueue.purgeQueue();
		}
		if(fDocument != null && fDocument.getLength() > 0) {
			DocumentEvent e=new DocumentEvent(...)
			createDirtyRegion(e)
			fThread.reset();
			fThread.suspendCallerWhileDirty();
		}
	}
}

The CReconciler is an incremental reconciler, and the the problem here is
the 
"fThread.suspendCallerWhileDirty()" causes us to wait until the reconciler
thread
runs again (it is blocked waiting on the fDirtyRegionQueue) .. nominally on
a 1s 
delay loop.

The fThread.reset() doesn't actually help with the notification since it
uses logic:

public void reset() {
	if(fDelay > 0) {
		synchronized(this) {
			fIsDirty = true;
			fReset = true;
		}
	} else {
		synchronized(this) {
			fIsDirty = true;
		}
		synchronized(fDirtyRegionQueue) {
			fDirtyRegionQueue.notifyAll();
		}
	}
	...
}

Note that since we use a fDelay of 1000 that we are forced to wait rather
than 
signalling that the queue needs to be serviced right now.  This is what
causes
the long delays on editor closes.

Other than changing the behaviour of our reconciler to be non-incremental
(ie we
will loose the detailed change information) is there another course of
action we
should be taking?  We can't notify ourselves since the fDirtyRegionQueue is
a 
private member and there is no accessor to that Object.  

Also setting the delay to 0 to become entirely event driven results in a
lock up 
in the run() method since there are two "wait()"'s in a row which mean that
in the
case of a straight open/close of an editor you get stuck in the second
notification.

Any comments on how we might approach this differently is appreciated.  Our
course of 
action for the 3.2 release right now is to make the reconciler
non-incremental (which is 
what JavaEditor does) but that doesn't seem to be the right general
approach.

Thanks,
 Thomas


Back to the top