C++ async example.

[chri...@lefty.io]

Hey there,

First of all thanks a lot for the amazing work (xoogler here, now extremely happy user of gRPC).
That being said, I'm having a pretty hard time figuring out the C++ asynchronous interface.

My first question is could someone be kind enough to give an example for those 3 scenario:

  -Fire a request and completely forget / not care about the result.
  -Fire a request, get some sort of future or RPC handle, (... do some other stuff...) then rpc.WaitFor() to
   block until completion.
  -Fire a request with a "done" closure to be executed when the call completes.


Second question is: how should one build the CompletionQueue* that async calls expect, on the client?
(I was trying to read through the async end to end test but the completion queue used by the client comes from
a serverBuilder, which kinda lost me).

Thanks a lot!

[Yang Gao]

Note there is a simple async client example at https://github.com/grpc/grpc-common/blob/master/cpp/helloworld/greeter_async_client.cc

1. What exactly do you want to achieve by the fire and forget rpc? It can be done by making a rpc and cancel it later, but this depends on the server does not check cancel status and stops processing rpc.

2. The above example shows exactly this, you can do other things before you call Next which serves as the rpc.WaitFor() you want.

3. I think you will need some thread polling the client side completion queue (which can be shared by different rpcs) and run the callback upon a finished rpc.

In the example code, you can also find that you just need to create a CompletionQueue locally and attach it to a rpc call and all the events will come back on the queue. The end2end test is no longer a good example of using the API.

Thanks.

[Christian Rivasseau]

Thanks this helps a lot and I think I understood 2 and 3.

Regarding 1 what I meant by Fire and forget it not cancel the RPC, I just mean send

the RPC to the server and move on without caring about the response.

Is this possible or do I still need a thread to poll the completion queue (to avoid leaks I assume?)

--
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+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/ed440ea4-d8a3-42f5-8e79-a81224dc1965%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Christian Rivasseau
Co-founder and CTO @ Lefty
+33 6 67 35 26 74

[yuf...@gmail.com]

Hi,

I am also interested in the fire and forget case. Is there any update on this use case?

I tried to stop the code at rpc->Finish() without calling cq.Next() to simulate the "forget" part, but it seems the server never receives the async client request in this case. I have to execute cq.Next() to make sure the server receives the request. However this will block the thread and not what I would like to achieve.

Thanks,

Una

On Tuesday, June 23, 2015 at 2:58:37 PM UTC-7, chri...@lefty.io wrote:

[Nathaniel Manista]

On Wed, Nov 9, 2016 at 2:30 PM, <yuf...@gmail.com> wrote:

I am also interested in the fire and forget case. Is there any update on this use case?

We talked about fire-and-forget around this time last year but didn't have a compelling use case at the time. You may wish to contribute to the discussion in this issue (don't be put off that it is closed).

-Nathaniel

[Vijay Pai]

This hasn't had a response in a while so I wanted to followup again. We don't allow fire-and-forget or for that matter anything that would allow more than 1 outstanding op on the same side of a stream without an intervening Next (or completed AsyncNext) for two key reasons: making sure that we have sane concurrency guarantees and reducing the likelihood of OOMing because of a lack of constraints. Either of these modes of operation can be implemented as a layer of code on top of gRPC, so we're not supporting them in the C/C++ API.

Regards,

Vijay