Feel free to take a look at this thread
- https://groups.google.com/d/topic/grpc-io/T9u2TejYVTc/discussion
I attached a C++ implementation of the RouteGuide Async server there. That
code avoids lot of boiler plate and integrates nicely with any threading
architecture you want. The code was written more than 1 year ago. I have a
variation of that (mostly for hooking up our custom application) but the
fundamentals are the same (meaning that sample code works in production).
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.
Hope that helps.
On Friday, October 12, 2018 at 9:35:38 AM UTC-7, Stephan Menzel wrote:
>
> Hello Christian
>
> Am Freitag, 12. Oktober 2018 12:12:16 UTC+2 schrieb Christian Rivasseau:
>>
>>
>> Then case to BaseMethod:
>>
>> bool ok;
>> while (true) {
>> if (!m_cq->Next(&tag, &ok)) break;
>>
>> MOOSE_ASSERT(ok);
>> static_cast<MyBaseMethod*>(tag)->proceed();
>> }
>>
>
> The pure inheritance solution you suggested was not very practical to me
> as I needed to have each call with it's own RequestType and ResponseType,
> which suggested a CRTP solution. I went for this plus some macros, which
> forced me to add an additional enum to identify the object and then static
> cast. Gotta say, lots of boilerplate I didn't see coming. Especially since
> the sync server where kind of neat and in-a-box.
>
> Anyway, it appears to work now and I can start tests next week.
>
> If I may still inquire, in case you or anybody else knows about the thread
> safety of the functions involved.
>
> The docs say somewhere that Next() is thread safe so multiple workers may
> serve requests.
>
> But what about the others involved? Specifically
> AsyncService::RequestMyMethod() and the shutdown methods Server::Shutdown()
> and CompletionQueue::Shutdown(). Can I safely have multiple threads doing a
> loop like we have them in the example?
>
> Thank you for your input!
> Stephan
>
>
--
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 [email protected].
To post to this group, send email to [email protected].
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/b5f8b3c4-c429-4d20-8fed-fd2b5f772b53%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
