Sorry for the delayed response. The CQ shouldn't be thought of as a FIFO queue primarily largely because in a highly-concurrent system like gRPC the definition of "first" is not very clear. These different alarms might have been resolved at and fired from different internal threads, for example, so they might hit the CQ in a different order than they were first put into the system. If you need to preserve FIFO order, you should probably do that by tagging your events with some sort of atomically incrementing value (for example) and then expecting those in sequence when pulling tags off the CQ.
On Sunday, February 24, 2019 at 4:10:27 PM UTC-8, Sumant Tambe wrote: > > Can you please elaborate on "nothing is guaranteed in-order at the CQ"? Is > it wrong to think about the CQ as a queue? > > Reiterating the original objective: to use grpc completion_queue to tunnel > non-grpc events so that the application event loop has only one queue to > wait on. The FIFO order of non-grpc events must be preserved. > > Sound like alarms is not the right path. "But Why" question is harder to > answer if Alarm is the answer. > > An alternative is grpc_cq_begin_op() and grpc_cq_end_op() APIs. However, > it looks like applications using this api directly is not desirable for > portability reasons. Is it desirable to the gRPC team to extend C or C++ > completion_queue design/implementation to facilitate insertion of > application-defined completed ops/tags? > > I'm not sure how the two approaches compare with respect to complexity, > intrusiveness, and hackiness spectrum. Thoughts? > > On Tue, 19 Feb 2019 at 22:26, 'Vijay Pai' via grpc.io < > [email protected] <javascript:>> wrote: > >> Sorry for the late response. To further what Sree said, any use of alarms >> at all is not a common case so we've never special cased any of this. I >> imagine that we could accept a PR but I also expect that it would have to >> pass the "but why" threshold. None of this is what we consider >> timing-sensitive as long as it's good enough. And to confirm Sree: nothing >> is guaranteed in-order at the CQ, regardless of timeout. >> >> On Friday, February 15, 2019 at 2:34:30 PM UTC-8, Sree Kuchibhotla wrote: >>> >>> Hi Sumant, >>> Zero timeout alarms is not a common case (Vijay can correct me here) and >>> so it wouldn't make sense to special-case this. >>> >>> -Sree >>> >>> On Fri, Feb 15, 2019 at 11:37 AM <[email protected]> wrote: >>> >>>> Hi Sree, >>>> >>>> Whoa! This behavior is such a gotcha. It seem you are saying >>>> immediately-firing alarms don't in fact "fire immediately", Right? Naively >>>> one would think that zero-deadline alarms would be optimized and would be >>>> queued right-away as there's no apparent reason for using a timer. That's >>>> just me though. >>>> >>>> Is it worth adding such an optimization in gRPC core? >>>> >>>> Thx a bunch for answering such a nuanced question promptly. >>>> >>>> Regards, >>>> Sumant >>>> >>>> On Friday, February 15, 2019 at 10:56:08 AM UTC-8, Sree Kuchibhotla >>>> wrote: >>>>> >>>>> Hi Sumant, >>>>> If you create two alarms with zero timeout in quick succession, then >>>>> they may not "fire" in the same order you created - and hence FIFO isn't >>>>> guaranteed here. However, if the alarms are created reasonably spaced >>>>> apart >>>>> (like for example: tens of millis apart), then yes -they fire in FIFO. >>>>> (Note that an alarm underneath creates a timer which when fired queues >>>>> the completion event in the completion queue. So we are really at the >>>>> mercy >>>>> of the grpc timer component.).. >>>>> >>>>> Hope this helps. >>>>> -Sree >>>>> >>>>> >>>>> On Fri, Feb 15, 2019 at 10:29 AM <[email protected]> wrote: >>>>> >>>>>> Hi Vijay, >>>>>> >>>>>> Just confirming that FIFO ordering of immediately-firing alarms is >>>>>> guaranteed by the complete_queue. Right? >>>>>> >>>>>> -Sumant >>>>>> >>>>>> On Friday, February 8, 2019 at 8:10:39 AM UTC-8, [email protected] >>>>>> wrote: >>>>>>> >>>>>>> Hi Vijay, >>>>>>> >>>>>>> 3,000,000 per second rocks! >>>>>>> Thx much everyone! >>>>>>> >>>>>>> Regards, >>>>>>> Sumant >>>>>>> >>>>>>> On Thursday, February 7, 2019 at 8:43:53 AM UTC-8, Vijay Pai wrote: >>>>>>>> >>>>>>>> I just created a pull request to benchmark immediately-firing >>>>>>>> alarms. The results on my Mac laptop suggest that you can fire at >>>>>>>> least >>>>>>>> 3,000,000 immediate alarms per second on a single thread, so I don't >>>>>>>> think >>>>>>>> you'll hit a limit from that. >>>>>>>> >>>>>>>> I would strongly advise against directly using >>>>>>>> grpc_cq_begin_op/grpc_cq_end_op . Those are internal functions and >>>>>>>> will >>>>>>>> change name/behavior whenever we choose. >>>>>>>> >>>>>>>> I should have some more information to announce on the callback API >>>>>>>> within the next few weeks but we continue to prepare it for >>>>>>>> production-readiness in both unary and streaming cases. >>>>>>>> >>>>>>>> - Vijay >>>>>>>> >>>>>>>> -- >>>>>> You received this message because you are subscribed to a topic in >>>>>> the Google Groups "grpc.io" group. >>>>>> To unsubscribe from this topic, visit >>>>>> https://groups.google.com/d/topic/grpc-io/NyjgbqHxTm8/unsubscribe. >>>>>> To unsubscribe from this group and all its topics, 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/98abb701-1b90-4c2f-87ea-821b83d17564%40googlegroups.com >>>>>> >>>>>> <https://groups.google.com/d/msgid/grpc-io/98abb701-1b90-4c2f-87ea-821b83d17564%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> -- >>>> You received this message because you are subscribed to a topic in the >>>> Google Groups "grpc.io" group. >>>> To unsubscribe from this topic, visit >>>> https://groups.google.com/d/topic/grpc-io/NyjgbqHxTm8/unsubscribe. >>>> To unsubscribe from this group and all its topics, 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/921b1360-8f74-484f-af53-6755715d9708%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/grpc-io/921b1360-8f74-484f-af53-6755715d9708%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "grpc.io" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/grpc-io/NyjgbqHxTm8/unsubscribe. >> To unsubscribe from this group and all its topics, 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/cb3be957-4d35-4fbb-9f4e-2f94bffd7088%40googlegroups.com >> >> <https://groups.google.com/d/msgid/grpc-io/cb3be957-4d35-4fbb-9f4e-2f94bffd7088%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- 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/50da584a-4bf9-487c-892f-45e19ebc648d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
