I'd like to know the design rationale for why gRPC services implementations are all concurrently executing singletons. There are many possible instancing and threading modes that could have been used.
- Singleton instancing - Per-call instancing - Per-session instancing - Concurrent execution - Sequential execution Concurrent singletons make sense from an absolute throughput angle - no object instantiation or blocking. But concurrent singletons are hardest for developers to work with - service implementors must be keenly aware of shared state and mult-threading concerns. 1. Why was concurrent singleton chosen as the only out-of-the-box way to implement gRPC (java) services? 2. Would API for supporting other threading and instancing modes be accepted in a PR? -- 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/4944f24c-f66a-414c-a0fd-d8baa77b82c7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
