Just to add some detail to this question, Alex and I work on a platform which exerts a lot of control over threads and allocations to guarantee high throughput and low latency. We would like to begin exposing gRPC services from the platform without compromising performance.
Our hope was to write an async server which would enqueue work in our own thread manager and go right back to listening for incoming requests. We have seen the APIs for controlling concurrency in both `ResourceQuota` and `CompletionQueue` (e.g. here <https://stackoverflow.com/a/52301414>) but it seems like there are still internal gRPC threads. So it comes down to these questions: *Can I control the total number of threads*, both short-lived and long-lived, that gRPR creates? If not, can I provide a strong guarantee about the max # of threads? (Getting arenas to work with our custom allocator is probably a topic for a future thread.) Thanks for your help, Jonathan On Wednesday, June 16, 2021 at 4:28:48 PM UTC-7 Alex Zuo wrote: > I am trying to understand how many internal threads gRPC creates in async > mode. I find some timer threads, and some threads in Executor. Are there > any threads? Are there any short-lived thread? > > Also are there any threads to receive bytes from socket and deserialize > them? > -- 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/4fba9ffc-0d00-40bc-887f-e5134a494f83n%40googlegroups.com.
