[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[cdt-dev] RE: [platform-text-dev] Closing CDT editors delayed by reconciler synchronization
|
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
>