[cdt-dev] RE: [platform-text-dev] Closing CDT editors delayed by reconci

[Thomas Fletcher <ThomasF@xxxxxxx>]

The text guys have indicated that this does look like a bug to them,
but short term there doesn't appear to be a good work around so I'm
going to flip the reconciler to a non-incremental mode for 3.2 and 
we'll work through it for 4.0 as part of the editor clean ups.

Thanks,
 Thomas

> -----Original Message-----
> From: platform-text-dev-bounces@xxxxxxxxxxx 
> [mailto:platform-text-dev-bounces@xxxxxxxxxxx] On Behalf Of 
> Thomas Fletcher
> Sent: Monday, April 17, 2006 10:25 AM
> To: platform-text-dev@xxxxxxxxxxx
> Cc: CDT General developers list.
> Subject: [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
> _______________________________________________
> platform-text-dev mailing list
> platform-text-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-text-dev
>