New forwarder demo in C++ #285
Conversation
bernardnormier
requested review from
pepone,
externl and
InsertCreativityHere
| target.ice_invokeAsync( | ||
| current.operation, | ||
| current.mode, | ||
| make_pair(inEncapsulationStart, inEncapsulationStart + inEncapsulationSize), |
There was a problem hiding this comment.
This is safe because the encapsulation for the input parameters is synchronously copied to OutgoingAsync. We don’t have a way to avoid this copy, right?
There was a problem hiding this comment.
Yes, the "marshaling" is always synchronous for Ice invocations, including ice_invokeAsync.
And indeed, the marshaling - even of bytes - always allocates a new buffer. There is no public API to transfer the ownership of the in-params InputStream to the in-params OutputStream.
For colloc, we have an internal API that does the opposite: "converts" an OutputStream into an InputStream.
https://github.com/zeroc-ice/ice/blob/4f7ba6a20a54c43c54891fc74494843107d78cd4/cpp/src/Ice/CollocatedRequestHandler.cpp#L136
Note that adopt is false, most likely for retries.
We do use "adopt = true" in the same file, in the implementation of sendResponse for colloc:
https://github.com/zeroc-ice/ice/blob/4f7ba6a20a54c43c54891fc74494843107d78cd4/cpp/src/Ice/CollocatedRequestHandler.cpp#L333
| slice2cpp_generate(server) | ||
| target_link_libraries(server Ice::Ice) | ||
|
|
||
| add_executable(forwardingserver Forwarder.cpp Forwarder.h ForwardingServer.cpp) |
There was a problem hiding this comment.
forwarding server is more consistent with the file names and C# names.
| // Make the invocation asynchronously. If `ice_invokeAsync` throws an Ice.LocalException that cannot be | ||
| // marshaled (such as Ice.ConnectionRefusedException), the object adapter that calls `dispatchAsync` converts it |
There was a problem hiding this comment.
Why remove these?
I think using quotes to distinguish between english and code is helpful to comprehension, and wish that we did more of this. Although I would use single quotes instead of backticks for these (personally).
Co-authored-by: Austin Henriksen <austin.r.henriksen79@gmail.com>
This is the C++ counterpart of #283.