MDS/openide
1
0
Fork 0
mirror of https://gitflic.ru/project/openide/openide.git synced 2026-09-27 10:03:11 +07:00
Code Issues Packages Projects Releases Wiki Activity

IDEA-CR-48225 AsyncFileListener: even more javadoc

Browse Source 
GitOrigin-RevId: 61feb3a3c9befa62a3ea530cda78d7860fbd9300
This commit is contained in:
peter
2019-06-12 14:21:14 +03:00
committed by intellij-monorepo-bot
parent 5d39400130
commit f751051ec3
1 changed files with 8 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
platform/core-api/src/com/intellij/openapi/vfs/AsyncFileListener.java
+8 -6
View File
@@ -17,8 +17,9 @@ import java.util.List;
*
* <h3>Migration of synchronous listeners:</h3>
*
* Synchronous listeners have two parts: "before" and "after", observing the state of the system before a VFS change. Since asynchronous
* listeners are executed before applying VFS events, they're more easily suited to "before" event processing.<p></p>
* Synchronous listeners have two flavours: "before" and "after"; observing the state of the system before and after a VFS change, respectively.
* Since asynchronous listeners are executed before applying VFS events, they're more easily suited to "before" event processing. Note that
* not all synchronous listeners need to be migrated, only those that might take noticeable time.<p></p>
*
* To migrate a "before"-handler, you need to split the listener into two parts: one that analyzes the events but has no side effects,
* and one which actually modifies some other subsystem's state based on these events. The first part then goes into {@link #prepareChange},
@@ -31,11 +32,12 @@ import java.util.List;
* In this case the check can go into {@link #prepareChange}, and the action based on it &mdash; into {@link ChangeApplier#afterVfsChange()}.
* <p></p>
*
* Otherwise you can just move the whole "after"-processing into {@link ChangeApplier#afterVfsChange()}. But make it as
* fast as possible to shorten the UI freezes.<p></p>
* When you migrate a listener with both "before" and "after" parts, you can try to just move the whole "after"-processing into
* {@link ChangeApplier#afterVfsChange()}. But make it as fast as possible to shorten the UI freezes.<p></p>
*
* If possible, consider moving heavy processing into background threads and/or
* performing it lazily. Note that it'll likely need a consistent model of the world, probably with the help of
* If possible, consider moving heavy processing into background threads and/or performing it lazily.
* There's no general solution, each "after" event processing should be evaluated separately considering the needs and contracts
* of each specific subsystem it serves. Note that it'll likely need a consistent model of the world, probably with the help of
* {@link com.intellij.openapi.application.ReadAction#nonBlocking} (and note that other changes might happen after yours, and
* the state of the system can change when your asynchronous handler starts). This might also
* introduce a discrepancy in the world when the VFS is already changed but other subsystems aren't, and this discrepancy