Bugzilla – Full Text Bug Listing
| Summary: | [Edit] Run diff computations as Jobs not Runnables | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Tomasz Zarna <tomasz.zarna> | ||||||
| Component: | Compare | Assignee: | Platform-Compare-Inbox <platform-compare-inbox> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | Tomasz Zarna <tomasz.zarna> | ||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | daniel_megert, kazm, prakash, pwebster | ||||||
| Version: | 3.7 | Keywords: | investigate | ||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | stalebug | ||||||||
| Bug Depends on: | 326330 | ||||||||
| Bug Blocks: | 304693, 326680, 326683 | ||||||||
| Attachments: |
|
||||||||
|
Description
Tomasz Zarna
Even though this bug looks like a blocker to bug 322329 I don't think a fix for this bug will be something we would like to backport to 3.6.x, which will eventually happen to bug 322329. Consider a scenario when you've opened two compare editors. As soon as the "Finding diffs" dialog shows up you hit cancel on it. The first algo is cancelled, but does the other one do? Of course, it hasn't been cancelled so it's still running. What's interesting the modal dialog stays up for that time, even though it doesn't show any progress and the Cancel button is disabled (you've just hit it for the first algo). As the result you have to wait for the second algo to stop without a way to cancel it. Once bug 307280 is fixed this could become a serious issue for long running uncapped diff algorithms! Prakash, you're an expert in that matter[1]. Is the above an expected behavior when we run multiple runnables via PlatformUI.getWorkbench().getProgressService().run(boolean, boolean, IRunnableWithProgress) (using ProgressManager in this particular case)? Or is there something wrong with our runnables or the way we run them? Is moving to Jobs the only option? [1] http://blog.eclipse-tips.com/2009/02/using-progress-bars.html The major problem seems to be not passing the IProgressMonitor down and not honoring the cancellation. So even if the user presses Cancel, nothing happens. Now that the related Bug# 322329 is fixed, as soon as the user presses cancel (and the operation responds to it), the dialog should go away. Is that not happening now? (In reply to comment #4) > Is that not happening now? It is, if you open a single compare editor. However if you schedule multiple comparisons (e.g. by opening files from the Sync view) you will get blocked with the dialog even though you have hit cancel on it. Apparently, the dialog is up as long as all scheduled runnabbles are running (see comment 0 and comment 2) Created attachment 179509 [details]
Patch that makes the "Finding diffs" dialog easier to observe
Created attachment 179510 [details]
mylyn/context/zip
From my initial investigation there is wrong ProgressMonitorDialog$ProgressMonitor instance notified about cancelation. I observed, that cancleation works only for last compared document. In other words when your are comparing e.g. 3 documents, it only works when you hit cancel on when first two has been compared and third is comparing. It may suggest, that there is always cancelled last created thread (I did not check it, it is only my guessing.) (In reply to comment #8) > It may suggest, that there is always cancelled last created thread I thought it's the other way round but I may be wrong. Anyway, can you confirm that the dialog is up blocking the user as long as long as at least one runnabble is running even though the Cancel has been hit? This is my major concern -- the blocking dialog with no way of closing it. Tomek, I am confirming that for all compared documents except last one the dialog blocks any user actions I can click "Cancle" but once I click it, the button becomes inactive and I must wait until comparing ends. What I also observed, that for me there is only one IrunableWithProgress running at the time. Next runnable starts only when comparing previous files ended. Moreover when comparing many files, there is opened new progress dialog for each file. When we talked with Tomek today, he said he has only one progress dialog for all files. Tomasz, can you confirm that? (In reply to comment #10) > When we talked with Tomek today, he said he has only one progress dialog > for all files. Tomasz, can you confirm that? Yes, I was pretty sure I was dealing with a single dialog. I had a chat with Prakash today during which he managed to reproduce the problem on his side. He also said that it looks like a single dialog. At the same time he hacked a sample plug-in that does the same thing Compare does with the Runnables but this time he got a separate dialog for each runnable. There is definitely something wrong going on here, and Prakash promised to take a closer look at it. Tomasz,
As I suspected, the IProgressService.run is called from two different threads. One checks whether its ok to open the editor and the other tries to computes the differences. When this (call from different threads to IProgressService.run) happens, and the user presses cancel, the UI appears to be frozen. I'm able to reproduce it without the team/compare coding. This is being addressed in the Bug# 326330
I'm holding off with targeting this bug to a particular milestone until bug 326330 gets addressed. If fixing that bug didn't solve the issue from comment 0, I would reconsider fixing this bug. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag. |