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, [email protected] 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 [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/1f3ee67d-7c5c-418f-b622-1207315076bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to