On Tue, Oct 3, 2017 at 1:32 AM Nathaniel Manista <[email protected]> wrote:
> 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? > I was confused (didn't think it through) about the local variables somehow being "shared" across calls. I have been able to verify and got my thinking straight about that not being the case. > -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/CANODV3n63TcWxixKjr-8iBf%2B79HpiGvdbTSO5O5fSZhJegqNfA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
