-
Notifications
You must be signed in to change notification settings - Fork 208
Completely dettach IO from parallel request execution #368
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
19bcdb2
to
8d166bf
Compare
c11d747
to
b20d77d
Compare
b20d77d
to
8982f0f
Compare
c4c763d
to
ffb6968
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From someone who is unfamiliar with the history of this project, this change seems to make a lot of sense.
One thing that I do want to ask, is if you'd thought at all about this ticket during the refactor: #443
It feels like they align quite well and at the very least would be worth documenting initial thoughts on how plugins could be added with the new code layout.
Otherwise it's looking good!
This refactor doesn't take much of the plugin mechanisms into consideration, but I don't think it makes it harder either. The way I'm currently thinking about it, we'll need to allow plugins to define middleware and overrides for requests and those will be loaded at boot. The plugins shouldn't interact with global store, queues and things like that, they should basically just have access to what the request implementation already has (generally the document and some extra parameters like position). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome work, this is really easy to follow now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job pulling off this huge rewrite. Anyway we can split the changes into multiple PRs/commits so it'd be easier to review?
ffb6968
to
c650841
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Just 2 nitpicks 🙂
Refactor the queue and server so that the handler holds all responsibility over the job queue and IO
c650841
to
0da8516
Compare
Motivation
Closes #378
Our request
Handler
class has leaked some responsibility over to the queue and server files. Both request definition and IO are now spread and that makes it difficult to guarantee that no IO will occur in the main request path.This refactor tries to centralize all request running logic into an
Executor
class while leaving all queue and IO managing to theHandler
. The only part that leaks into theHandler
is defining which requests must be run sequentially inside the main process (typically client notifications and life cycle requests).Implementation
Before
server.rb
Handler
andQueue
work together to decide how to execute and finalize requests, as well as managing the request queueon_error
configuration block inserver.rb
to show error message notifications, but we are unable to send more than one notification to the client (e.g.: we wouldn't be able to clear diagnostics for a file and display a dialogue in the same request)After
Executor
class knows how to run all requests (except for requests that need access to the main process - either the queue or the thread worker). It is basically a big case statement that matches the feature to a method containing the implementationExecutor
, every request returns a response and all notifications (which should not return a response) returnVoid
@notifications
variable, which is an array of notifications to be returned to the client. For example, this allows us to return a response, clear diagnostics and show a dialogue to the user all within the same requestHandler
class manages the queue and decides which requests are run sequentially or in parallel. All IO happens here, which should make parallelism a bit easier. We can run requests in separate processes, get the response back and then write to IOWhat should reviewers focus on
Manual tests
Please, take the time to play around with the LSP on this branch to see if you can make it break. I tested on a few projects and things seem to be fine.