Support canceling requests and drop superseded server requests #347
Comments
|
Agreed, though we have to make a distinction between two types of requests here:
The former already happens in the base package for (re)indexing requests and also for signature help; they will wait a while until things stabilize before sending a request to the server. Once that happens, however, it is "too late" to take them back. This brings us to the latter. Currently, core 3.0 does not internally queue any requests and just takes them from the socket, processing them one by one. As such, canceling requests is pretty much impossible as they are still floating in the socket and the core is processing the events before any cancel request first, including the one that is supposed to be canceled. Coincidentally, however, I've already updated the core to drain the socket as fast as possible and queue the requests separately. This means that in theory, it is now possible to support request cancellation in the core and base client. (IIRC, the language server protocol also added this in version 2.) To summarize, this is something I want to do sooner or later, and it requires support in both the core and the base package. |
Gert-dev
changed the title
With the queue, the first reindex request for a series of them was always sent and left to be handled completely, whilst only the last of any subsequent requests was maintained in order to skip unnecessary intermediate ones. This way the core did not have to play catch up. The unfortunate part was that the first reindex request always went through, even if the core was very busy handling other requests and could not handle that first request until a while later, after which that first request might also have been superseded. As the request had already been sent, however, there was no way to cancel it. As the core now has request cancellation support, it is simpler to let all reindex requests pass through to the core and just cancel the ones that aren't relevant. This automatically allows us to cancel even the first request, at least if it wasn't being processed yet - but that was also the case before. In short, this should improve latency on slower hardware where many actions are being performed simultaneously. References #347
Sometimes queries and re indexing are slow, this causes several auto complete and call tip requests to get queued up. Which in turn then causes me to wait until all requests are handled by the integrator core, one by one.
It would be much better, when outstanding requests of the same kind would be canceled and only the latest one of them handled.
The text was updated successfully, but these errors were encountered: