Hello everyone, I am trying to understand the general architecture of the underlying architecture of the* sync server* threading logic, and especially the way completion queues and thread managers work together.
>From wandering on the internet I keep swinging between different ideas: My first understanding was that each CompletionQueues have a pollset (all the fds in the pollset binds to the same port (SO_REUSEPORT)) and everytime it receives an event, it hands it out to a thread from the thread manager. But the PollForWork done by threads in the thread manager made me rethink this ^ basic approach. Threads could do the actual polling, waiting for requests from clients and then push requests into the CQ with its tag. CQ thread would then unqueue the request and handle it. I saw a couple of projects using async server and using multiple completion queues with only on thread per queue, while the sync server architecture use a threads pool per queue. So in a nutshell, I am wondering: - Who is doing the actual polling and reading the RPC requests from clients, the ThreadManager (and its threads) through PollForWork(), or the CompletionQueues ? - Is the CQ running in a different thread from the TManager ? I saw that there is a ThreadManager per CQ. - Why do we need multiple CQs ? Thank you for your time, Regards, Terence -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/db6cf6c4-c25b-480e-8911-98c3d564b7b4%40googlegroups.com.
