From e39e0bb0cedf36c2f47d0c5254acfc1f21e7cf3e Mon Sep 17 00:00:00 2001
From: Karol Lewandowski
Date: Thu, 20 Feb 2025 15:53:48 +0100
Subject: [PATCH] Minor Execution Context links fixes
---
.../coroutines/coroutine_edt_and_locks.md | 4 ++--
.../threading/execution_contexts.topic | 18 ++++++------------
2 files changed, 8 insertions(+), 14 deletions(-)
diff --git a/topics/basics/architectural_overview/threading/coroutines/coroutine_edt_and_locks.md b/topics/basics/architectural_overview/threading/coroutines/coroutine_edt_and_locks.md
index fabeec797..50cf89f8f 100644
--- a/topics/basics/architectural_overview/threading/coroutines/coroutine_edt_and_locks.md
+++ b/topics/basics/architectural_overview/threading/coroutines/coroutine_edt_and_locks.md
@@ -161,7 +161,7 @@ Sometimes it is not desired, as the coroutine in question was scheduled on [`Dis
Anyway, it is suspicious when a read action cannot be executed on a background thread and a part of coroutine code cannot be suspended and rescheduled on EDT.
This may signal a code issue.
-Note that this API cannot be used in the [blocking context](execution_contexts.topic#blocking-context).
+Note that this API cannot be used in the [Blocking Context](execution_contexts.topic#blocking-context).
### Suspending `readAndWriteAction()`
@@ -176,7 +176,7 @@ Consider rewriting code to use it, if possible.
Use them if a read action is required, but it is unacceptable to reschedule code execution on a different dispatcher.
-These APIs are marked to use only in the [blocking context](execution_contexts.topic#blocking-context), so their usage in the [suspending context](execution_contexts.topic#suspending-context-coroutines) will trigger a warning.
+These APIs are marked to use only in the [Blocking Context](execution_contexts.topic#blocking-context), so their usage in the [Suspending Context](execution_contexts.topic#suspending-context-coroutines) will trigger a warning.
It is intentional, as coroutines should be prepared to be rescheduled and should use `readAction()`.
### Suspending `writeIntentReadAction()` and Blocking `WriteIntentReadAction.run()`/`compute()`
diff --git a/topics/basics/architectural_overview/threading/execution_contexts.topic b/topics/basics/architectural_overview/threading/execution_contexts.topic
index 369cb59c8..f5142a0c8 100644
--- a/topics/basics/architectural_overview/threading/execution_contexts.topic
+++ b/topics/basics/architectural_overview/threading/execution_contexts.topic
@@ -11,9 +11,6 @@
The IntelliJ Platform provides APIs that allow tracking the progress of background processes and canceling their
execution when they are canceled by a user, or they become obsolete due to some changes in the data model.
-
-
-
Available execution contexts differ depending on the IntelliJ Platform version.
For the details, select the required tab below.
@@ -21,7 +18,7 @@
Background processes can be executed in two contexts:
- — available since 2024.2
+ — available since 2024.2
— obsolete since 2024.1
@@ -31,15 +28,14 @@
can be considered obsolete.
- Starting with 2024.2, it is recommended to execute new code in the .
+ Starting with 2024.2, it is recommended to execute new code in the .
The following sections explain the contexts and provide information about process cancellation, progress
tracking, and switching between contexts.
-
-
+
@@ -105,11 +101,11 @@
Executing tasks in the Blocking Context means executing them on a thread without access to the coroutine context (basically, in non-suspending functions)
- and not under the Progress Indicator.
+ and not under the .
Such tasks can still be canceled, but they can't report progress.
Plugins should not execute new code in the Blocking Context.
- Always prefer executing tasks in the Suspending Context or
- under the Progress Indicator if a plugin cannot use Kotlin.
+ Always prefer executing tasks in the Suspending Context
+ or under the if a plugin cannot use Kotlin.
Functions which schedule execution via
@@ -405,5 +401,3 @@
-
-