[C++] CompletionQueue::Next() return vs ok parameter value

[Przemysław Sobala]

Hello

What is the difference between method's

bool CompletionQueue::Next(void** tag, bool* ok)

return value and 2nd parameter's value?

Reading docs, it says:

/// \param ok[out] true if read a regular event, false otherwise.
/// \return true if read a regular event, false if the queue is shutting down

Following the example:

while (true) {
	// Block waiting to read the next event from the completion queue. The
	// event is uniquely identified by its tag, which in this case is the
	// memory address of a CallData instance.
	// The return value of Next should always be checked. This return value
	// tells us whether there is any kind of event or cq_ is shutting down.
	GPR_ASSERT(cq_->Next(&tag, &ok));
	GPR_ASSERT(ok);
	static_cast<CallData*>(tag)->Proceed();
	}

it breaks whether the return value or ok parameter is false.

But in the production environment maybe I can break the loop when the queue is shutting down (based on return value) and continue when ok parameter's value is false?

What is the most preferable approach? Should I consider both of them as the same and break on false as in the example?

--

regards

Przemysław Sobala

[Yang Gao]

Usually we have a loop calling Next and when we are sure there will be no more work adding to the completion queue we call completion queue's Shutdown method to shutdown the queue.

It will in turn cause the Next to return false and it can be used to break out of the loop.

The ok parameter is an indication of the success of that particular operation and usually is not related to the cq life time management. 

[谭锦彪]

Hi

I meet the situation that the Next return true, but ok==false, howerer, the content of the tag is right, tag->status.ok() return true, tag->reply is right too, That confuse me,

why would this situation happen? Could I ignore the check of ok?

在 2017年8月2日星期三 UTC+8上午6:57:16，Yang Gao写道：

[Mark D. Roth]

I'm not sure what you mean when you refer to tag->status and tag->reply.  The gRPC API does not define a particular API for the tag; that's entirely up to your application code, so I have no idea what those fields represent or how they are being set.

Yang's earlier description is correct: the ok parameter is an indication of whether the operation corresponding to the returned tag was successful.  What a failure means depends on what the operation was.  If it was a RequestCall(), then it means that the completion queue is shutting down and you can stop listening for new calls.  For any request as part of a call (e.g., a read or a write), it means that there was a problem with the operation and you should call Finish() to get the call's final status.

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to grp...@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/35ece217-c182-4dd9-b779-bbe8bf6b58d3%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Mark D. Roth <ro...@google.com>
Software Engineer
Google, Inc.

[谭锦彪]

Hi Roth,

Thanks for your reply, about the refer to tag, you can see greeter_async_client2.cpp, my client code is just like it, but the server code has complex work to do. 

Sometimes, ok is false but call->status.ok() is true, and call->reply.message() is right. That happens very frequent in my situation, and currently, I ignore it, do not check ok, and the program working properly, but I worried if there will some undefined things happen.

So that confused me,  if the response of the grpc server is correct, why the ok equals false?

void AsyncCompleteRpc() {

        void* got_tag;

        bool ok = false;

        // Block until the next result is available in the completion queue "cq".

        while (cq_.Next(&got_tag, &ok)) {

            // The tag in this example is the memory location of the call object

            AsyncClientCall* call = static_cast<AsyncClientCall*>(got_tag);

            // Verify that the request was completed successfully. Note that "ok"

            // corresponds solely to the request for updates introduced by Finish().

            GPR_ASSERT(ok);

            if (call->status.ok())

                std::cout << "Greeter received: " << call->reply.message() << std::endl;

            else

                std::cout << "RPC failed" << std::endl;

            // Once we're complete, deallocate the call object.

            delete call;

        }

    }

在 2017年9月1日星期五 UTC+8下午10:10:25，Mark D. Roth写道：

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.
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/35ece217-c182-4dd9-b779-bbe8bf6b58d3%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Mark D. Roth]

If the tag being returned from the completion queue is the result of a Finish() call, then I think ok should always be true, even if the status is not okay.  This is because the underlying op in C-core always succeeds:

https://github.com/grpc/grpc/blob/master/include/grpc/impl/codegen/grpc_types.h#L470

Is this a unary or streaming RPC?  If it's streaming, then perhaps you're getting a tag back from something other than Finish() (e.g., a send or recv message op)?  In that case, the individual op may fail but the call's overall status will not yet have been received -- that doesn't happen until after the tag from Finish() is returned.

To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscribe@googlegroups.com.

To post to this group, send email to grp...@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/f2d9dbda-9a4a-4283-ab13-0cf57b0547a9%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[谭锦彪]

I agree with you, but it really happend, and in high frequency, maybe it's a bug?

It's a unary RPC.

在 2017年9月6日星期三 UTC+8上午12:26:14，Mark D. Roth写道：

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/f2d9dbda-9a4a-4283-ab13-0cf57b0547a9%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Mark D. Roth]

Can you put together a standalone example that reproduces the problem?  If so, please file a bug that includes the example, and someone will take a look.

To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscribe@googlegroups.com.

To post to this group, send email to grp...@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/d5a6f5b7-b118-4ce3-b800-2f42c2304f8b%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.