Run long-spanning tasks cancellably on background in the (Java) LSP server. #7708
Conversation
|
I think we need to make progress on this. |
lahodaj
added
Java
lahodaj
changed the title
lahodaj
force-pushed
the
java-lsp-server-compute-long-spanning-tasks-cancellably-on-background
branch
from
a768cee to
71e959b
Compare
|
FWIW: I've changed the implementation to an explicit priority "queue", as the original patch with injecting tasks in the editor background infrastructure proved to be too complex, at least for now. |
lahodaj
force-pushed
the
java-lsp-server-compute-long-spanning-tasks-cancellably-on-background
branch
from
49bb7f8 to
a7f0d23
Compare
|
I limitation of this way to cancel things is that it cannot stop computations inside javac/parser. Unlike the previous round which used the "editor" tasks, which can stop even javac/parser. But, this patch:
|
| public void cancel(); | ||
| } | ||
|
|
||
| public final class CancelCheck { |
There was a problem hiding this comment.
Is this supposed to be a public class? It is currently used only within this class.
| } | ||
|
|
||
| public void registerCancel(CancelCallback callback) { | ||
| cancelCallback.set(callback); |
There was a problem hiding this comment.
Perhaps throw an IllegalStateException if a callback is already registered.
| void cancel() { | ||
| cancelled.set(true); | ||
|
|
||
| CancelCallback callback = cancelCallback.get(); |
There was a problem hiding this comment.
It would be easier to verify the thread-safety of these methods if the accesses to cancelled and cancelCallback were synchronized as a unit, rather than just being individually protected by AtomicBoolean/AtomicReference.
But in practice I assume registerCancel is going to be called up-front, before concurrent accesses start.
| private final P data; | ||
| private final CompletableFuture<R> result; | ||
|
|
||
| public TaskDescription(CancellableTask<P, R> task, P data, CompletableFuture<R> result) { |
There was a problem hiding this comment.
Perhaps add null checks on parameters so that NPEs happen immediately and with a useful stack trace, rather than with a delay.
|
|
||
| private CancelCheck() {} | ||
|
|
||
| public boolean isCancelled() { |
There was a problem hiding this comment.
Shouldn't this be called somewhere from TextDocumentServiceImpl? Whenever I do cancelable operations, I usually have a loop of batch operations with an if (isCanceled()) break; somewhere.
@jtulach reported the code completion inside VS Code is sometimes slow for him. I was thinking of that, and experimenting, and I think at least part of the problem is that tasks that should be background tasks are not properly cancellable in the VS Code (Java) server.
I was doing experiments on:
https://github.com/openjdk/jdk/blob/master/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
and it seemed there were two (current) particular pain points:
Neither of these can be cancelled when the request to compute code completion. This draft is attempting to improve that, and run diagnostics and semantic coloring in a cancellable way.
It only properly cancels for Java sources at this time, for other sources runs only the CompletableFuture cancel will work. Some work on Schedulers will be needed to fully enable this for non-Java sources, but I suspect this can wait
I also have a separate PR that adds additional logging for code completion:
#7815