Skip to main content

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

Hi Thomas,

looking at that code I'd say it's a bug: it should first check whether
there's anything in the dirty queue and only if it isn't empty make sure
that the document is correctly reconciled with the model. Please file a bug
report against Platform Text.

An easier workaround than switching to non-incremental reconciling might be
to implement uninstall() in your reconciler like this (but you must be sure
that the document and the model are either correctly reconciled, or it's
not important since the editor gets closed):
  setIsIncrementalReconciler(false);
  super.uninstall();
  setIsIncrementalReconciler(true);

HTH
Dani


                                                                           
             Thomas Fletcher                                               
             <ThomasF@xxxxxxx>                                             
             Sent by:                                                   To 
             platform-text-dev         platform-text-dev@xxxxxxxxxxx       
             -bounces@eclipse.                                          cc 
             org                       "CDT General developers list."      
                                       <cdt-dev@xxxxxxxxxxx>               
                                                                   Subject 
             17.04.2006 16:25          [platform-text-dev] Closing CDT     
                                       editors delayed by reconciler       
                                       synchronization                     
             Please respond to                                             
             Eclipse Platform                                              
              Text component                                               
              developers list                                              
             <platform-text-de                                             
              v@xxxxxxxxxxx>                                               
                                                                           
                                                                           




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




Back to the top