[orc-rt] Add ControllerAccess interface. #169598
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ControllerAccess provides an abstract interface for bidirectional RPC between the executor (running JIT'd code) and the controller (containing the llvm::orc::ExecutionSession). ControllerAccess implementations are expected to implement IPC / RPC using a concrete communication method (shared memory, pipes, sockets, native system IPC, etc). Calls from executor to controller are made via callController, with "handler tags" (addresses in the executor) specifying the target handler in the controller. A handler must be associated in the controller with the given tag for the call to succeed. This ensures that only registered entry points in the controller can be used, and avoids leaking controller addresses into the executor. Calls in both directions are to "wrapper functions" that take a buffer of bytes as input and return a buffer of bytes as output. In the ORC runtime these must be `orc_rt_WrapperFunction`s (see Session::handleWrapperCall). The interpretation of the byte buffers is up to the wrapper functions: the ORC runtime imposes no restrictions on how the bytes are to be interpreted. ControllerAccess objects may be detached from the Session prior to Session shutdown, in which case no further calls may be made in either direction, and any pending results (from calls made that haven't returned yet) should return errors. If the ControllerAccess class is still attached at Session shutdown time it will be detached as part of the shutdown process. The ControllerAccess::disconnect method must support concurrent entry on multiple threads, and all callers must block until they can guarantee that no further calls will be received or accepted.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
ControllerAccess provides an abstract interface for bidirectional RPC between the executor (running JIT'd code) and the controller (containing the llvm::orc::ExecutionSession). ControllerAccess implementations are expected to implement IPC / RPC using a concrete communication method (shared memory, pipes, sockets, native system IPC, etc).
Calls from executor to controller are made via callController, with "handler tags" (addresses in the executor) specifying the target handler in the controller. A handler must be associated in the controller with the given tag for the call to succeed. This ensures that only registered entry points in the controller can be used, and avoids leaking controller addresses into the executor.
Calls in both directions are to "wrapper functions" that take a buffer of bytes as input and return a buffer of bytes as output. In the ORC runtime these must be
orc_rt_WrapperFunctions (see Session::handleWrapperCall). The interpretation of the byte buffers is up to the wrapper functions: the ORC runtime imposes no restrictions on how the bytes are to be interpreted.ControllerAccess objects may be detached from the Session prior to Session shutdown, in which case no further calls may be made in either direction, and any pending results (from calls made that haven't returned yet) should return errors. If the ControllerAccess class is still attached at Session shutdown time it will be detached as part of the shutdown process. The ControllerAccess::disconnect method must support concurrent entry on multiple threads, and all callers must block until they can guarantee that no further calls will be received or accepted.