Available execution contexts differ depending on the IntelliJ Platform version. For the details, select the required tab below.
@@ -21,7 +21,7 @@Background processes can be executed in two contexts:
@@ -29,44 +29,36 @@ As the platform's execution model moves towards coroutines, this approach can be considered obsolete. -Starting with 2024.2, it is recommended to execute new code in the - Job context.
+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.
- -Code executed in Kotlin coroutines is executed in the Job context. +
Code executed in Kotlin coroutines is executed in the Coroutine Execution Context. Since 2024.2, coroutines are recommended for executing background tasks to maximize CPU utilization. Note that executing code in coroutines is possible only with Kotlin.
- While code executed in the Job context should use suspending functions,
+ While code executed in the Coroutine Execution Context should use suspending functions,
sometimes it is required to call non-suspending/blocking APIs that use methods such as
ProgressManager.checkCanceled() or ModalityState.defaultModalityState().
- Since 2024.2, these methods work as expected without the need to switch to the blocking context.
+ Since 2024.2, these methods work as expected without the need to switch to the Blocking Context.
Job class, which is used for task cancellation in suspending and non-suspending
- functions.
- Inspection
Starting with 2024.1, it is recommended to execute new code in the - suspending context.
+ Suspending Context.Code executed in Kotlin coroutines is executed in a suspending context. +
Code executed in Kotlin coroutines is executed in the Suspending Context. Since 2024.1, this context is recommended for executing background tasks to maximize CPU utilization. Note that executing code in coroutines is possible only with Kotlin.
-In a suspending context, methods such as ProgressManager.checkCanceled() or ModalityState.defaultModalityState()
+
In the Suspending Context, methods such as ProgressManager.checkCanceled() or ModalityState.defaultModalityState()
won't have any effect.
Therefore, if their behavior is required, switch to a blocking
context.
Inspection
Executing tasks in a blocking context means executing them on a thread without access to the 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 a progress indicator. + and not under the Progress Indicator. 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.
+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.
Functions which schedule execution via Application.executeOnPooledThread()
- and similar methods, and which rely on ProgressManager.checkCanceled()
- should be annotated with @RequiresBlockingContext
- to inform clients about the required switch to a blocking context.
Functions which schedule execution via
+
+ Application.executeOnPooledThread()
+ and similar methods, and which rely on
+
+ ProgressManager.checkCanceled() should be annotated with
+
+ @RequiresBlockingContext to inform clients about the required switch to
+ the Blocking Context.
Inspection
ProgressManager,
ProgressIndicator,
etc.)
- is executed in a progress indicator context.
+ is executed in the Progress Indicator execution context.
See the section for details.
Executing code under the progress indicator is obsolete since 2024.1. +
Executing code under the Progress Indicator is obsolete since 2024.1. It is advised to use Kotlin coroutines in new code.
Please note that obsolete status does not mean deprecation.
Executing code using the Progress API is still allowed, but coroutines are recommended as a more
@@ -167,7 +159,7 @@