On Fri, Sep 29, 2017 at 5:14 PM, Amit Saha <[email protected]> wrote:
> I decided to use server context because i assumed that it would be a > request local object. > Instances of grpc.ServicerContext <https://grpc.io/grpc/python/grpc.html#grpc.ServicerContext> are indeed per-RPC objects, but their role is to afford certain data and behaviors to service-side applications and to accept certain other data from service-side applications. We'd be reluctant to expand their scope to include "a place to put stuff until later". When my server is handling concurrent requests, i would not want to use a > local variable to keep state (without any locking i.e). > If your application has state that you only need to last as long as the evaluation of a single behavior (per-RPC state), why is a behavior-local field ("local variable") not the right place to store that state? -N -- 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/CAEOYnASB6_RgtofCmDFnnajHGBF0-Or733kA6sWhme9Cfuj0NA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
