Bugzilla – Full Text Bug Listing
| Summary: | Workbench windows do not close with busy event queue | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Marc R. Hoffmann <hoffmann> |
| Component: | UI | Assignee: | Eric Moffatt <emoffatt> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | emoffatt, giachelini, pwebster, remy.suen |
| Version: | 3.7.1 | Flags: | pwebster:
review+
|
| Target Milestone: | 3.7.2 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Marc R. Hoffmann
This was trying to chew up SWT.Close events (at least that's what the comments say). Eric, the brute force fix would be like adding a boolean to break out from the loop, set in an asyncExec(*) ... so that would be processed *after* any outstanding SWT OS events (like a pending SWT.Close). Of course, that assumes I understand how display.readAndDispatch() works :-) PW I propose the following fix: Instead of looping until the queue is empty from my understanding we simply need to wait until all events are processed, that were submitted before shellClosed() is called. If we schedule a simple sync command this should have exactly this effect.
My proposed fix is to replace the while loop in canHandleShellCloseEvent() with the following snippet:
// Wait until all pending 'Close' events are processes
getWorkbench().getDisplay().syncExec(new Runnable() {
public void run() {
}
});
This fix works with the Windows 7 "Close Group" feature (I don't have access to XP right now to verify). It also solves the problem that the canHandleShellCloseEvent() hangs forever.
Is there any chance to get this fixed in 3.7.2? Unfortunately this issue is currently a complete show stopper for us.
Can anybody retest my proposed fix? We urgently need this for 3.7.2. Many thanks, -marc Paul and I were just discussing the fix for this and think that we've come up with a compromise that'll work... Before we start running the loop we'll initiate an asynchExec that, when *it* runs will force the exit of the loop. This has the advantage of purging any events that exist in the queue at the time we get called but not any ones that come in later. I'll post the code snippet here once I have it...;-) Thanks great! As soon as you post the proposed fix we'll test it against our scenario.
Marc, here's the snippet we expect to contribute to 3.7.2...
final boolean[] boundingAsynchDone = { false }; Display.getCurrent().asyncExec(new Runnable() {
public void run() {
boundingAsynchDone[0] = true;
}
});
// Ensure that any pending 'Close' event are flushed
// before opening any dialogs
while (!boundingAsynchDone[0] && Display.getCurrent().readAndDispatch())
;
The theory is that this will allow the queue to purge but *only* until it hits the bounding asynch then closes (this should prevent us from endlessly spinning.
Could you please give this a try ?
I re-tested the Close Groups scenario with the 'synchExec' snippet and it doesn't seem to work for those cases, perhaps this will cover both.
Eric, the fix seems to works for our "busy queue" scenario. We will perform additional long-running tests over the weekend. Many thanks! Eric, even our extended test scenarios did run successfully with your patch. Thanks! Approved for 3.7.2 PW Released to 3.7.2 and 3.8. http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=9e42a7a2e9217efb510257ca38300f722d521f7b http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=66f6b21a942c5178fe68faa948ade7596f535b56 Eric, do we have equivalent code in 4.x? PW . |