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写道：
>
> 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.
>
> On Thu, Aug 31, 2017 at 11:30 PM, 谭锦彪 <[email protected] <javascript:>>
> wrote:
>
>> 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写道：
>>
>>> 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.
>>>
>>>
>>> On Monday, July 10, 2017 at 2:32:37 AM UTC-7, Przemysław Sobala wrote:
>>>>
>>>> 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
>>>>
>>> --
>> 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] <javascript:>.
>> To post to this group, send email to [email protected]
>> <javascript:>.
>> 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
>>
>> <https://groups.google.com/d/msgid/grpc-io/35ece217-c182-4dd9-b779-bbe8bf6b58d3%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Mark D. Roth <[email protected] <javascript:>>
> Software Engineer
> Google, Inc.
>
--
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/f2d9dbda-9a4a-4283-ab13-0cf57b0547a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
