Bugzilla – Full Text Bug Listing
| Summary: | Blocked UI warning occurs multiple times simultaneously | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Kim Horne <eclipse> | ||||||
| Component: | UI | Assignee: | Tod Creasey <Tod_Creasey> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | daniel_megert, Darin_Swanson, john.arthorne, n.a.edgar, pascal, philippe_mulet, snorthov, Tod_Creasey | ||||||
| Version: | 3.0 | ||||||||
| Target Milestone: | 3.0 M9 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Kim Horne
Created attachment 7901 [details]
BAM!
*** Bug 52001 has been marked as a duplicate of this bug. *** If anyone reproduces it, a stack trace would be useful. *** Bug 53315 has been marked as a duplicate of this bug. *** There needs to be a guard in EventLoopProgressMonitor or ProgressManager to avoid opening a second "blocked" dialog if one is already open, just like ProgressMonitorDialog and ModalContext maintain a progress depth. I will look into this. *** Bug 54522 has been marked as a duplicate of this bug. *** *** Bug 57006 has been marked as a duplicate of this bug. *** *** Bug 57998 has been marked as a duplicate of this bug. *** *** Bug 59967 has been marked as a duplicate of this bug. *** Created attachment 10079 [details]
Patch to org.eclipse.ui.workbench
Here is a patch to fix the workbench portion of this problem. The
BlockedJobsDialog now uses a static singleton, so that recursive blockages can
reuse the same dialog. The dialog is only closed when the outermost monitor to
block on it is finished. Recursive monitors can access the dialog's monitor to
check for user cancelation requests.
The core portion of this problem has been fixed and released. The problem was this: - Each recursive blockage in the stack queued a job and waited for that job to be executed - Since jobs with conflicting rules are processed in FIFO order, the job corresponding to the bottom-most blockage on the stack was granted execution first. Meanwhile, the blockage at the top of the stack is still spinning in a loop and waiting for its job to execute. It will never execute, since it is blocked by the job for the blockage at the bottom of the stack. - It was usually still possible for the user to cancel out of this deadlock by dismissing all the blocked dialogs in front of them. The fix, unfortunately, is to NOT queue a job when threads are blocked, but rather use a polling loop to attempt to acquire the scheduling rule. This means queued blockages will not be processed in FIFO order, but instead the rule would be obtained by the first polling loop to grab the rule. This guarantees that in the case of recursive blockage, the top-most blockage will get the rule first, and the stack will eventually unwind. The singleton blocked jobs dialog is only closed when the stack has unwound completely. As the core code has already been released, I will move this over to Tod to release my patch to the workbench. Released with some modifications/refactorings to fit the current state of the workbench. |