On Friday, October 12, 2018 at 1:53:15 PM UTC-7, Arpit Baldeva wrote:
> As for boiler plate, yeah, the async grpc version forces lot of it. So the
> implementation above and a custom code generator plugin can go a long way
> into making that process nice. For example, with a custom code generator,
> you can generate the boilerplate like generating the instances of above
> templated rpcs and calling them to register with grpc core lib. Note that
> I am not proposing doing away with grpc_cpp_plugin.exe but simply creating
> a companion that is able to generate the boilerplate specific to your
> application.
A project I worked on in the past year took exactly this helper library+code
generation approach. The helper library [1] had a bunch of abstractions,
like one that represented the server-side state of one async, in-progress
method invocation in a well-typed way [2] & [3].
Our custom codegen tool (which was based on a language similar to ProtoBuf)
knew how to generate service base classes that used these abstractions [4]
& [5].
The library also imposed a callback-based async model [6] and took care of
reading from completion queues itself [7].
By imposing these restrictions atop the gRPC++ library, we were able to
simplify implementation of async services [8]:
class GreeterServiceImpl final : public Greeter::Service
{
public:
using Greeter::Service::Service;
private:
void SayHello(bond::ext::grpc::unary_call<HelloRequest, HelloReply>
call) override
{
HelloRequest request = call.request().Deserialize();
HelloReply reply;
reply.message = "hello " + request.name;
call.Finish(reply);
}
};
Some of these ideas may help others build abstractions for their projects.
When I left the project, only unary calls had been implemented in C++.
Streaming was in progress--and they appear to not yet have been implemented.
There was also work left to make it possible to share an io_manager among
multiple servers and clients (to reduce the number of threads that were just
idle), and to use multiple completion queues to reduce some lock contention
we were seeing inside of the gRPC completion queue because we were just
using one completion queue for all I/O operations within a server.
[1]: https://microsoft.github.io/bond/manual/bond_over_grpc.html
[2]:
https://github.com/Microsoft/bond/blob/bd4b46e78a82dd3a38b52b00233a1a22047014d2/cpp/inc/bond/ext/grpc/unary_call.h#L19-L32
[3]:
https://github.com/Microsoft/bond/blob/bd4b46e78a82dd3a38b52b00233a1a22047014d2/cpp/inc/bond/ext/grpc/detail/unary_call_impl.h#L42-L56
[4]:
https://github.com/Microsoft/bond/blob/bd4b46e78a82dd3a38b52b00233a1a22047014d2/compiler/tests/generated/service_grpc.h#L415
[5]:
https://github.com/Microsoft/bond/blob/bd4b46e78a82dd3a38b52b00233a1a22047014d2/cpp/inc/bond/ext/grpc/detail/service.h#L151-L159
[6]:
https://github.com/Microsoft/bond/blob/bd4b46e78a82dd3a38b52b00233a1a22047014d2/cpp/inc/bond/ext/grpc/scheduler.h#L14-L28
[7]:
https://github.com/Microsoft/bond/blob/bd4b46e78a82dd3a38b52b00233a1a22047014d2/cpp/inc/bond/ext/grpc/io_manager.h
[8]:
https://github.com/Microsoft/bond/blob/bd4b46e78a82dd3a38b52b00233a1a22047014d2/examples/cpp/grpc/helloworld/helloworld.cpp#L18-L33
--
Christopher Warrington
Microsoft Corp.
--
You received this message because you are subscribed to the Google Groups
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit
https://groups.google.com/d/msgid/grpc-io/2803e2cb-bf37-4d1c-995b-86ac58915269%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
