I have been messing around with using AsyncNext.  My long-term plan is to 
have some timer that calls back and checks if there is anything in the 
completion queue via AsyncNext.  For now, I've just been trying to get some 
basics to work.  Below I have the code I'm using.  (Ignore the sleeping for 
now, that's just so it loops a little slower for debugging purposes.)  The 
issue is, while I do get AsyncNext returning with ok=true and a valid tag, 
I do not get anything when I try to read from the stream.  Am I not using 
the stream correctly?

    std::unique_ptr<gRPCMdtDialout::AsyncService> service2;
    service2.reset(new gRPCMdtDialout::AsyncService());

    ServerBuilder builder;
    builder.AddListeningPort(addr, grpc::InsecureServerCredentials());
    std::unique_ptr<grpc::ServerCompletionQueue> cq = 
    std::unique_ptr<Server> server(builder.BuildAndStart());

    ServerContext ctx_;
    ServerAsyncReaderWriter<MdtDialoutArgs, MdtDialoutArgs> stream_(&ctx_);
    service2->RequestMdtDialout(&ctx_, &stream_, cq.get(), cq.get(), this);

    while (true) {
        void *tag = NULL;
        bool ok = false;
        bool ret = cq->AsyncNext(&tag, &ok, gpr_time_0(GPR_CLOCK_REALTIME));
        if (ret == 1 && ok) {
            MdtDialoutArgs args;
            stream_.Read(&args, tag);
            cout << " read " << args.ByteSizeLong() << " " << args.reqid() 
<< endl;


On Monday, March 12, 2018 at 12:14:46 PM UTC-7, Yang Gao wrote:
> Hi Todd,
> Sorry for the late reply.
> You are right that Next will block until next event is coming out. 
> For your purpose, you may want to use AsyncNext with a deadline for a 
> server with async service.
> The deadline should be the next time point that you want to break out to 
> do something else on the server.
> Note grpc library needs to use the thread donated via Next or AsyncNext to 
> do some background work and thus only AsyncNext infrequently with very 
> short deadline may not be a good idea.
> Also, regarding the single-threadedness, the current grpc implementation 
> creates internal threads to do background work such as timer handling and 
> others. As a result, you will not have a truly single-threaded server even 
> if you only use one thread for the server.
> This may not be the final form as we intended to support threading model 
> fully controlled by the user. However, there is no timeline for those 
> background threads to be removed at the moment.
> On Thursday, February 22, 2018 at 11:01:37 AM UTC-8, Todd Defilippi wrote:
>> I am trying to write a streaming server as part of implementing a gRPC 
>> dial-out collector for Cisco's model-driven telemetry (
>> ).
>> Is there a way to create the gRPC server with C++ that does not require 
>> blocking?  The basic synchronous examples all require blocking, which will 
>> not work, so I have been looking at the various asynchronous examples.  I 
>> haven't been able to get those to work but I'm not sure I'm doing it 
>> correctly.
>> It seems like I would want to in some way use the CompletionQueues to 
>> hold messages that come in and process them when I can.  Is there a reason 
>> I would want to use Next() versus AsyncNext() (it seems the former blocks 
>> and the latter does not but I'm not sure)?  How does the combination of 
>> RegisterService() and AddCompletionQueue() work?
>> Thanks,
>> Todd

You received this message because you are subscribed to the Google Groups 
"" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
To post to this group, send email to
Visit this group at
To view this discussion on the web visit
For more options, visit

Reply via email to