Skip to content

Don't use display thread for scheduling console update tasks#2461

Open
iloveeclipse wants to merge 8 commits intoeclipse-platform:masterfrom
iloveeclipse:issue_2460
Open

Don't use display thread for scheduling console update tasks#2461
iloveeclipse wants to merge 8 commits intoeclipse-platform:masterfrom
iloveeclipse:issue_2460

Conversation

@iloveeclipse
Copy link
Member

This fixes regression from 7e1f60c, where main thread (which owns lock on UI operations) waits for the lock on ProcessConsole to update console name but never gets it because console code is blocked internally waiting for a QueueProcessingJob being executed on UI thread.

The solution is to avoid direct calls from UI to ProcessConsole.resetName().

Fixes #2460

Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR fixes a deadlock issue (#2460) that occurred when terminating launches. The deadlock happened because the UI thread would wait for a lock on ProcessConsole to update the console name, while console code was blocked waiting for a QueueProcessingJob to execute on the same UI thread. The fix introduces a separate ScheduledExecutorService to handle console name updates asynchronously, avoiding direct calls from the UI thread to ProcessConsole.resetName().

Changes:

  • Replaced UI thread timer-based scheduling (Display.timerExec) with a dedicated ScheduledExecutorService for console name updates
  • Added proper executor cleanup in the dispose() method
  • Introduced tracking of pending name update tasks to avoid duplicate scheduling

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@iloveeclipse
Copy link
Member Author

@trancexpress : if you can reproduce, please try this PR.

Beside this, I wonder if this task that updates console every second must be always executed, even if console is hidden behind other one. This is definitely a resource waste. Start ~6 processes with Console and enjoy that every 100 ms some task is executed updating some of the consoles.

This makes no sense. So probably the code has to be rewritten to avoid parallel updates of hidden console pages.

@trancexpress
Copy link
Contributor

I wasn't able to reproduce the deadlock when I tried. Likely it needs stepping with breakpoints, I've not checked how to do that.

@github-actions
Copy link
Contributor

github-actions bot commented Feb 20, 2026

Test Results

 1 977 files  ±0   1 977 suites  ±0   1h 26m 59s ⏱️ - 10m 21s
 4 743 tests ±0   4 719 ✅ ±0   24 💤 ±0  0 ❌ ±0 
14 229 runs  ±0  14 047 ✅ ±0  182 💤 ±0  0 ❌ ±0 

Results for commit 3d746e1. ± Comparison against base commit 63797d0.

♻️ This comment has been updated with latest results.

Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated 6 comments.

Comments suppressed due to low confidence (1)

debug/org.eclipse.ui.console/src/org/eclipse/ui/console/IConsole.java:127

  • The documentation contains a grammatical error: "is not more visible" should be "is no longer visible".
	 * this console is not more visible to user.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

- Extracted common code from ShowConsoleViewJob to AbstractConsoleJob
- Renamed RepaintJob to RedrawJob, switched to use AbstractConsoleJob
- Extracted anonymous UI job to WarnAboutContentChangedJob, based on
AbstractConsoleJob
- fWarnQueued is not needed anymore for WarnAboutContentChangedJob
- This above fixes the race condition where multiple consoles changes
could have triggered the warnOfContentChange(), but the job only
scheduled for the first one
- Moved final field inits to constructor
- Fixed potential NP in RedrawJob

See eclipse-platform#2477
`page.findView(IConsoleConstants.ID_CONSOLE_VIEW)` API doesn't return
console views opened in same page with secondary id's (== any Console
views opened next to the first one in same page). So all calls to
`ConsoleManager.refresh(IConsole)` were not working for such views. In
SDK, this would only affect `TextConsole.addHyperlink()` code and is
visible if opening Java Stack Trace view as secondary view - it will not
show hyperlinks.

Worse, since view id's are persisted across sessions, such views would
not work properly as long as they present in the perspective.

For the fix, make use of views registered in ConsoleManager and iterate
over them, similar to ShowConsoleViewJob code.

See eclipse-platform#2477
Original code had multiple issues: it didn't notified about console
content changes in all opened windows, it didn't notified for the
console changes in all secondary console views but it notified even if
the console with changes was visible.

As noticed already before,
`page.findView(IConsoleConstants.ID_CONSOLE_VIEW)` API doesn't return
console views opened in same page with secondary id's (== any Console
views opened next to the first one in same page). So
WarnAboutContentChangedJob only supported Console views without
secondary ids and only in the currently active window.

- Notify console changes in all windows, not only in the active one
- Notify also for secondary consoles
- Don't notify about console changes if changed console page is visible
(== top of the stack) in the current Console view and Console view is
also visible.

Fixes eclipse-platform#2477
- Moved final field inits to constructor
- Get rid of unneeded or duplicated code, obsoleted comments
- Use instanceof variables
- Fix spelling mistakes
- Changed all access to fActiveConsole via get/set methods
- Moved final field inits to constructor
- Added trivial toString() implementation to the AbstractConsole
- Moved final field inits to constructor
- Removed useless javadocs
- Use instanceof variables where possible
- Added "disposed" field and checks before each asyncExec() for that
- Refactored computeName() to readable code
-- split into multiple logical parts
-- made things static which are static
-- don't do anything if view is already disposed
This fixes regression from 7e1f60c, where main thread (which owns lock
on UI operations) waits for the lock on ProcessConsole to update console
name but never gets it because console code is blocked internally
waiting for a QueueProcessingJob being executed on UI thread.

The solution is to avoid direct calls from UI to
ProcessConsole.resetName().

Fixes eclipse-platform#2460
- Added new API to allow console pages knew whether they are visible or
not.
- Use new IConsole API to schedule console updates only if console page
is visible (top level) in the console view. This prevents multiple
opened consoles in same console view run update tasks every second, even
if no one can see the updated console name.

Fixes eclipse-platform#2478
Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated 1 comment.


💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

3 participants