Thanks for the comments. 1. The async streaming example will happen in the relatively near future, most probably when the callback API is considered production-ready. Meanwhile, I can suggest that you use some of the codes in test/cpp/end2end or test/cpp/qps as models of the async streaming API 2. We have lots of codes running like this in production and haven't seen this sort of behavior. As the previous responder pointed out, putting a sleep in an async-processing loop is a ltitle suspect so can this simply be the result of unusual code being tested 3. This is indeed the expected behavior and our test/cpp/end2end_test looks at this with CLOCK_REALTIME . Can you give a sample code where you're seeing blocking when giving a deadline in the past? 4. TCP_NODELAY is the default for all sockets created in gRPC for Posix systems. We would prefer to expose higher-level concepts through the API like latency-sensitive, throughput-sensitive, etc. But this is something that we could provide in the future; we have a socket mutator option to set socket features but the API is not final or stable at the current time. Can I suggest that you file a feature request in our Github repo for this so that it can be prioritized and tracked?
gRPC launches its own threads in two categories: executor and timer. The executor is used for DNS resolution as well as offloading certain tasks that are off the critical path (certain writes in the transport layer etc). The timer threads are used for maintaining all the tracking of time in gRPC for timing-sensitive features of the transport or the API (like alarms). Otherwise the work is done in the application's own threads when it calls CQ::Next or a blocking RPC method. - Vijay On Tuesday, March 19, 2019 at 12:13:45 PM UTC-7, Jeff wrote: > > Great, here’s some feature requests (now that I am sure I have the right > forum): > > 1) Add an async streaming example to your cpp example code. Launching a > thread per connection is somewhat wasteful, so streaming and async go hand > in hand. It is a large omission. > 2) When c++ grpc app is spinning on cq->next, it serves clients in a > non-uniform manner. A *very* non-uniform manner. Clients can starve. This > should be addressed, as it does not seem like an uncommon use case. > 3) AsyncNext takes a deadline. If that deadline is 0 (using any > gpr_clock_type) I expect it to return immediately if there is nothing in > the queue. This happens for GPR_CLOCK_PRECISE but for no others. There > should simply be a TryNext method. > 4) It would be nice if there was some way to specify socket options. ie > TCP_NODELAY and other such options should be readily accessible. Not > supporting this is more than just an inconvenience for a programmer imo. > > Also, please clarify the threads grpc launches at startup (for C++, or in > general if it is all the same). Can you enumerate them and briefly discuss > their purpose? > > Thank you so much. > > > > > > > > > -- 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/08b78007-129d-4db1-8168-304c769476cb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
