You should not need to manage your own threads for basic callback usage,
that’s one of the callback API’s design goals (
https://github.com/grpc/proposal/blob/master/L67-cpp-callback-api.md#proposal
).
Take a look at the route_guide example here:
https://github.com/grpc/grpc/blob/v1.41.x/examples/cpp/route_guide/route_guide_callback_client.cc.
It has a server-streaming client for ListFeatures, a client-streaming
client for RecordRoute, a bidi client for RouteChat, and the recommended
“shortcut” method of making a client unary call via
`stub->async()->GetFeature(…)`, where the lambda stands in for a
ClientUnaryReactor’s OnDone method (
https://github.com/grpc/grpc/blob/v1.41.x/examples/cpp/route_guide/route_guide_callback_client.cc#L304).
For streaming operations, gRPC manages threads to call the reactor
callbacks asynchronously. If the application needs to wait for some
streaming operation to finish, it *can* block the main thread using
something like the custom Await method of the ListFeatures Reader, but
that's entirely optional and up to the application developer.
Hope that helps!
On Tuesday, September 7, 2021 at 2:22:47 PM UTC-7 oleg@idt.net wrote:
> Hello, could you possibly help me with creating async callback client?
> Should I create UnaryClientReactor per rpc or I should run every rpc in
> separate thread?
> There cq-based async client example but callback client example looks like
> sync rpc with thread blocking.
>
> Thank you.
>
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/grpc-io/26dc90da-e003-47fa-bef8-01bb44d88647n%40googlegroups.com.