Had a question: How can we multipllex connections over handful of CQs? Dont all the individual client (represented by its unique *tag*) have to poll on the CQs in its own thread? Which means we need N number of threads to call 'next' on the CQ for N *tags* . Right?
On Monday, May 14, 2018 at 8:21:56 AM UTC-7, jojy.v...@gmail.com wrote: > > Thanks for the response. I wish there was a 'polling' interface for grpc. > > > > On Thursday, May 10, 2018 at 12:00:55 PM UTC-7, Christopher Warrington - > MSFT wrote: >> >> On Wednesday, May 9, 2018 at 2:05:32 PM UTC-7, jojy.v...@gmail.com wrote: >> >> >>> For every connection, we should be able to get the events unique to >> that >> >>> connection in completion queue >> >> >> Pretend you had such an API. Can you share how you would make us of it >> >> and what higher-level problem it would let you solve? >> >> >> >> There may be a different way to solve the same problem that doesn't >> need >> >> a per-connection completion queue... >> >> > We could then do things like act as a proxy service. Clients trying to >> > connect to an external server would be redirected to this service. This >> > service will then make a connection to actual server for each connected >> > client and forward the RPC (of course after some kind of processing that >> > involves some policy ). >> >> How do you plan to poll all these completion queues? There's no >> pollset-like >> API for completion queues. I can see two ways to poll a bunch of >> completion >> queues, neither of which looks scalable: >> >> 1. Have a dedicated poller thread per completion queue. >> * This will result in lots of threads that are mostly idle. Stack >> space >> is wasted, there will be scheduling overhead, &c. >> 2. Have a small number of poller therads and use >> grpc_completion_queue_next >> with a small, but non-zero deadline and cycle to the next completion >> queue to check when GRPC_QUEUE_TIMEOUT is returned. >> * Completion queues with work that are "behind" completion queues >> with >> no work will get starved. >> >> Instead, I think you want to explore an architecture where you multiplex >> all >> the client connections over a handful of completion queues. In the data >> structures you use for to track the outstanding operations (typically what >> you pass the address of as the void* tag value), one of the values could >> be >> a client identifier that you could use for whatever client-specific logic >> you need in your processing. >> >> Hope this helps. >> > -- 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+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@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/30c87fb5-bde0-498b-acd8-8dc63fa103f4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
