negotiateFunction.
These cases were accidentally left out of r292055, resulting in a less
descriptive ECError being returned on these paths.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292193 91177308-0d34-0410-b5e6-96231b3b80d8
negotiateFunction where appropriate.
Replacing the old ECError with a custom type allows us to attach the name of
the function that could not be negotiated, enabling better diagnostics for
negotiation failures.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292055 91177308-0d34-0410-b5e6-96231b3b80d8
handlers, make abandonPendingResults public API.
This should make installing asynchronous result handlers thread safe.
The abandonPendingResults method is made public so that clients can disconnect
from a remote even if they have asynchronous handlers awaing results from that
remote. The asynchronous handlers will all receive "abandoned result" errors as
their argument.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291399 91177308-0d34-0410-b5e6-96231b3b80d8
APICalls allows groups of functions to be composed into an API that can be
registered as a unit with an RPC endpoint. Doing registration on a-whole API
basis (rather than per-function) allows missing API functions to be detected
early.
APICalls also allows Function membership to be tested at compile-time. This
allows clients to write static assertions that functions to be called are
members of registered APIs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291380 91177308-0d34-0410-b5e6-96231b3b80d8
This brings MultiThreadedRPCEndpoint's addHandler API in-line with
SingleThreadedRPCEndpoint's.
This will be tested in an up-coming unit-test for MultiThreadedRPCEndpoint.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291376 91177308-0d34-0410-b5e6-96231b3b80d8
The lock needs to be acquired before the data is sent, not afterwards. This
think-o slipped in during the refactor in r286620, but went unnoticed as the
resulting bug only manifests in multi-threaded clients (of which there are none
in-tree).
No unit test as the bug depends on thread scheduling.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291216 91177308-0d34-0410-b5e6-96231b3b80d8
multiple asynchronous RPC calls.
ParallelCallGroup allows multiple asynchronous calls to be dispatched,
and provides a wait method that blocks until all asynchronous calls have
been executed on the remote and all return value handlers run on the
local machine.
This will allow, for example, the JIT client to issue memory allocation calls
for all sections in parallel, then block until all memory has been allocated
on the remote and the allocated addresses registered with the client, at which
point the JIT client can proceed to applying relocations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290523 91177308-0d34-0410-b5e6-96231b3b80d8
return types.
This class allows user provided handlers to return either error-wrapped types
or plain types. In the latter case, the plain type is wrapped with a success
value of Error or Expected<T> type to fit it into the rest of the serialization
machinery.
This patch allows us to remove the RPC unit-test workaround added in r286646.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286701 91177308-0d34-0410-b5e6-96231b3b80d8
This is a temporary fix: The right solution is to make sure addHandler can
support mutable lambdas. I'll add that in a follow-up patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286661 91177308-0d34-0410-b5e6-96231b3b80d8
(1) Add support for function key negotiation.
The previous version of the RPC required both sides to maintain the same
enumeration for functions in the API. This means that any version skew between
the client and server would result in communication failure.
With this version of the patch functions (and serializable types) are defined
with string names, and the derived function signature strings are used to
negotiate the actual function keys (which are used for efficient call
serialization). This allows clients to connect to any server that supports a
superset of the API (based on the function signatures it supports).
(2) Add a callAsync primitive.
The callAsync primitive can be used to install a return value handler that will
run as soon as the RPC function's return value is sent back from the remote.
(3) Launch policies for RPC function handlers.
The new addHandler method, which installs handlers for RPC functions, takes two
arguments: (1) the handler itself, and (2) an optional "launch policy". When the
RPC function is called, the launch policy (if present) is invoked to actually
launch the handler. This allows the handler to be spawned on a background
thread, or added to a work list. If no launch policy is used, the handler is run
on the server thread itself. This should only be used for short-running
handlers, or entirely synchronous RPC APIs.
(4) Zero cost cross type serialization.
You can now define serialization from any type to a different "wire" type. For
example, this allows you to call an RPC function that's defined to take a
std::string while passing a StringRef argument. If a serializer from StringRef
to std::string has been defined for the channel type this will be used to
serialize the argument without having to construct a std::string instance.
This allows buffer reference types to be used as arguments to RPC calls without
requiring a copy of the buffer to be made.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286620 91177308-0d34-0410-b5e6-96231b3b80d8
SequenceNumberManager.
Sadly, we don't have any unittests for this class because it is
a private class. Since it seems to have a nice isolated and testable
interface, it'd be great to extract it to a detail namespace and write
unit tests for it as then we could catch issues. I'll probably pester
Lang about that or some alternative refactoring.
This was noticed by PVS-Studio.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285990 91177308-0d34-0410-b5e6-96231b3b80d8
All of these existed because MSVC 2013 was unable to synthesize default
move ctors. We recently dropped support for it so all that error-prone
boilerplate can go.
No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284721 91177308-0d34-0410-b5e6-96231b3b80d8
It should forward to deregisterEHFramesInProcess by default, not
registerEHFramesInProcess.
No test case: I haven't come up with a good way to unit test EH frame
registration yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283123 91177308-0d34-0410-b5e6-96231b3b80d8
class.
SerializationTraits provides serialize and deserialize methods corresponding to
the earlier functions, but also provides a name for the type. In future, this
name will be used to render function signatures as strings, which will in turn
be used to negotiate and verify API support between RPC clients and servers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281254 91177308-0d34-0410-b5e6-96231b3b80d8
Still no unit test due to synchronization bugs on s390. These issues were
discovered in an out-of-tree utility.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280163 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r280016, and the followups of r280017, r280027,
r280051, r280058, and r280059.
MSVC's implementation of std::promise does not get along with
llvm::Error. It uses its promised value too much like a normal value
type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280100 91177308-0d34-0410-b5e6-96231b3b80d8
behaviors, and add a callB (blacking call) primitive.
callB is a blocking call primitive for threaded code where the RPC responses are
being processed on a separate thread. (For single threaded code callST should
continue to be used instead).
No unit test yet: Last time I commited a threaded unit test it deadlocked on
one of the s390x builders. I'll try to re-enable that test first, and add a new
test if I can sort out the deadlock issue.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280051 91177308-0d34-0410-b5e6-96231b3b80d8
Optional.
For void functions the return type of a nonblocking call changes from
Expected<future<Optional<bool>>> to Expected<future<Error>>, and for functions
returning T the return type changes from Expected<future<Optional<T>>> to
Expected<future<Expected<T>>>.
Inner results need to be checked (since the RPC connection may have dropped
out before a result came back) and Error/Expected provide stronger checking
requirements. It also allows us drop the crufty 'optionalToError' function and
just collapse Errors in the single-threaded call primitives.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280016 91177308-0d34-0410-b5e6-96231b3b80d8
switch to using one indirect stub manager per logical dylib rather than one per
input module.
LogicalDylib is a helper class used by the CompileOnDemandLayer to manage
symbol resolution between modules during lazy compilation. In particular, it
ensures that internal symbols resolve correctly even in the case where multiple
input modules contain the same internal symbol name (which must to be promoted
to external hidden linkage so that functions in any given module can be split
out by lazy compilation). LogicalDylib's resolution scheme (before this commit)
required one stub-manager per input module. This made recompilation of functions
(by adding a module containing a new definition) difficult, as the stub manager
for any given symbol was bound to the module that supplied the original
definition. By using one stubs manager for the whole logical dylib symbols can
be more easily replaced, although support for doing this is not included in this
patch (it will be implemented in a follow up).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279952 91177308-0d34-0410-b5e6-96231b3b80d8
ExecutionEngine::runFunction is supposed to allow execution of arbitrary
function types, but MCJIT can only reasonably support a limited subset of
main-linke function types. This patch documents this limitation, and fixes
MCJIT::runFunction to abort with a meaningful error at runtime if called with
an unsupported function type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278348 91177308-0d34-0410-b5e6-96231b3b80d8
