mirror of
https://github.com/JetBrains/intellij-sdk-code-samples.git
synced 2025-07-30 18:27:49 +08:00
general_threading_rules.md: do not use deflist
This commit is contained in:
parent
201e401466
commit
8c613b3bd6
@ -30,17 +30,17 @@ You may not modify PSI, VFS, or project model from inside UI renderers or `Swing
|
||||
To pass control from a background thread to the [Event Dispatch Thread](https://docs.oracle.com/javase/tutorial/uiswing/concurrency/dispatch.html) (EDT), instead of the standard `SwingUtilities.invokeLater()`, plugins should use `ApplicationManager.getApplication().invokeLater()`.
|
||||
The latter API allows specifying the _modality state_ ([`ModalityState`](upsource:///platform/core-api/src/com/intellij/openapi/application/ModalityState.java)) for the call, i.e., the stack of modal dialogs under which the call is allowed to execute:
|
||||
|
||||
`ModalityState.NON_MODAL`
|
||||
: The operation will be executed after all modal dialogs are closed. If any of the open (unrelated) project displays a per-project modal dialog, the action will be performed after the dialog is closed.
|
||||
#### `ModalityState.NON_MODAL`
|
||||
The operation will be executed after all modal dialogs are closed. If any of the open (unrelated) project displays a per-project modal dialog, the action will be performed after the dialog is closed.
|
||||
|
||||
`ModalityState.stateForComponent()`
|
||||
: The operation can be executed when the topmost shown dialog is the one that contains the specified component or is one of its parent dialogs.
|
||||
####`ModalityState.stateForComponent()`
|
||||
The operation can be executed when the topmost shown dialog is the one that contains the specified component or is one of its parent dialogs.
|
||||
|
||||
None specified
|
||||
: `ModalityState.defaultModalityState()` will be used. This is the optimal choice in most cases that uses the current modality state when invoked from UI thread. It has special handling for background processes started with `ProgressManager`: `invokeLater()` from such a process may run in the same dialog that the process started.
|
||||
#### None Specified
|
||||
`ModalityState.defaultModalityState()` will be used. This is the optimal choice in most cases that uses the current modality state when invoked from UI thread. It has special handling for background processes started with `ProgressManager`: `invokeLater()` from such a process may run in the same dialog that the process started.
|
||||
|
||||
`ModalityState.any()`
|
||||
: The operation will be executed as soon as possible regardless of modal dialogs. Please note that modifying PSI, VFS, or project model is prohibited from such runnables.
|
||||
#### `ModalityState.any()`
|
||||
The operation will be executed as soon as possible regardless of modal dialogs. Please note that modifying PSI, VFS, or project model is prohibited from such runnables.
|
||||
|
||||
If a UI thread activity needs to access [file-based index](indexing_and_psi_stubs.md) (e.g., it's doing any project-wide PSI analysis, resolves references, etc.), please use `DumbService.smartInvokeLater()`.
|
||||
That way, it is run after all possible indexing processes have been completed.
|
||||
@ -85,4 +85,4 @@ There are two recommended ways of doing this:
|
||||
In both approaches, always check at the start of each read action, if the objects are still valid, and if the whole operation still makes sense (i.e., not canceled by the user, the project isn't closed, etc.).
|
||||
With `ReadAction.nonBlocking()`, use `expireWith()` or `expireWhen()` for that.
|
||||
|
||||
If the activity has to access [file-based index](indexing_and_psi_stubs.md) (e.g., it's doing any project-wide PSI analysis, resolves references, etc.), use `ReadAction.nonBlocking(...).inSmartMode()`.
|
||||
If the activity has to access [file-based index](indexing_and_psi_stubs.md) (e.g., it's doing any project-wide PSI analysis, resolves references, etc.), use `ReadAction.nonBlocking(...).inSmartMode()`.
|
||||
|
Loading…
x
Reference in New Issue
Block a user