Skip to content

Synchronize lazy initialization in ProcessConsoleManager.getColorProvider#2805

Open
vogella wants to merge 1 commit into
eclipse-platform:masterfrom
vogella:fix-2637-colorprovider-init-race
Open

Synchronize lazy initialization in ProcessConsoleManager.getColorProvider#2805
vogella wants to merge 1 commit into
eclipse-platform:masterfrom
vogella:fix-2637-colorprovider-init-race

Conversation

@vogella

@vogella vogella commented Jul 7, 2026

Copy link
Copy Markdown
Contributor

Problem

ConsoleCreation jobs run in parallel but share the singleton ProcessConsoleManager. getColorProvider(String) lazily initialized fColorProviders (a plain HashMap) and the default ConsoleColorProvider without synchronization, so concurrent first calls could corrupt the map via parallel put() or create two different default providers (#2637).

Fix

Initialize both lazily in a lock-free way, so no lock is held across the extension-registry calls (which could deadlock with 3rd-party code):

  • fColorProviders is volatile and built into a local map before being published; a concurrent duplicate build is harmless because each thread fills its own local map.
  • The default provider is stored in an AtomicReference and created via compareAndSet, guaranteeing a single shared instance.

Intentionally isolated to the init race (#2637); the shared stateful default provider (#2638 / #596) is left for a follow-up.

Fixes #2637

@github-actions

github-actions Bot commented Jul 7, 2026

Copy link
Copy Markdown
Contributor

Test Results

    54 files  ±0      54 suites  ±0   58m 22s ⏱️ -43s
 4 685 tests ±0   4 663 ✅ ±0   22 💤 ±0  0 ❌ ±0 
11 949 runs  ±0  11 796 ✅ ±0  153 💤 ±0  0 ❌ ±0 

Results for commit 1fece62. ± Comparison against base commit fe3597d.

♻️ This comment has been updated with latest results.

ConsoleCreation jobs run in parallel and share the singleton
ProcessConsoleManager. getColorProvider(String) lazily initialized the
fColorProviders map and the default color provider without any
synchronization, so concurrent jobs could corrupt the HashMap during
parallel put() calls and could create and return two different default
color providers.

Initialize both lazily in a lock-free way so no lock is held across calls
into the extension registry (which could deadlock with 3rd party code):

- fColorProviders is volatile and built into a local map before being
  published. A concurrent duplicate build is harmless because each thread
  fills its own local map and only the published reference is used.
- The default color provider is stored in an AtomicReference and created
  via compareAndSet, guaranteeing a single shared instance.

Fixes eclipse-platform#2637

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@vogella vogella force-pushed the fix-2637-colorprovider-init-race branch from 3730df3 to 1fece62 Compare July 7, 2026 09:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Race condition when initializing ProcessConsoleManager.fColorProviders

2 participants