Restructure remote node processes and allow for multiple connections #434
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Current design
So far we would start a top-level
Manager
process on the remote node. This process would then configure the node (register stderr, logger, compiler opts), handle evaluation requests and then clean up on termination. Given the configure-cleanup logic, we generally enforced only a singleManager
process per node, and used some additional configuration to handle the Embedded runtime.New design
Now we split the
Manager
into separate pieces:NodeManager
- similarly to the current manager, it's the primary process we start and it configures and cleans up the given node. It then spawns a number ofRuntimeServer
processes - each for an individual runtime connection. When allRuntimeServer
s terminate, the manager itself also terminates and does the necessary cleanup.RuntimeServer
- a remote process behind each%Runtime{}
. It's simply responsible for orchestrating evaluation/completion - in short it builds on top ofEvaluator
s to satisfy the requirements of theRuntime
protocol.To initialize a remote node we start a
NodeManager
and then allow for arbitrarily many runtime connections, each getting it's ownRuntimeServer
. Once all connections are closedNodeManager
automatically cleans up and unloads the dynamically loaded modules.Implications
Separating node configuration and runtime requests logic makes for a nice refactoring. This also unifies
Embedded
runtime with other runtime types much more. Finally this makes it possible to connect multiple sessions to the same node usingAttachedRuntime
(cc @brainlid).