Hmm, I'm not finding good open-source examples of ThreadLocal context propagation in C++ and Java. My experience with this is based on what Google uses internally. Perhaps someone more familiar with context use (tracing?) outside Google can chime in? +Jaana Burcu Dogan <j...@golang.org>
On Thu, May 11, 2017 at 7:02 AM <mhhc...@gmail.com> wrote: > thanks, > > ..integrating Context into the runtime.. > > > 50% runtime, 50% syntax with explicit contextualization. > > ..The flow of request processing in Go may include multiple goroutines and > may move across channels; > > > yes big ? mark here. might the 50% of an handy and explicit syntax help > with it? > > > C++ and Java use thread-local Contexts, and while this is convenient, it > is often a source of mysterious bugs. > > thanks! I don't know them, > > I quickly checked according to this > https://dzone.com/articles/painless-introduction-javas-threadlocal-storage > I may have totally wrong, the syntax does not look like, not even from a > 100km, > to how i represent go contexts in my head. > > This is more like the actor pattern dave cheney talks about in > https://dave.cheney.net/2016/11/13/do-not-fear-first-class-functions > (search for Let’s talk about actors) > > Is the dzone link correctly describe > what you mentioned as being go context equivalent in java ? > > sorry my questions are so basic. > > > On Thursday, May 11, 2017 at 12:29:11 PM UTC+2, Sameer Ajmani wrote: > >> I think you are asking whether we considered integrating Context into the >> runtime, so that it does not need to be passed explicitly. Yes, we >> discussed this, but decided against it. The flow of request processing in >> Go may include multiple goroutines and may move across channels; we decided >> an explicit Context made this much easier to get right. C++ and Java use >> thread-local Contexts, and while this is convenient, it is often a source >> of mysterious bugs. >> > On Thu, May 11, 2017 at 4:08 AM <mhh...@gmail.com> wrote: >> >>> Thanks a lot! >>> >>> Might i guess and try to generalize your explanations into >>> "we tried to write a plumber for all cases possible" >>> >>> Which matters a lot, in my humble opinion. >>> >>> At least for the various reasons you put there, >>> simply put, >>> because it seems not technically achievable. >>> >>> Still i m happy you gave me those details, they are of interest indeed. >>> >>> I rather intent to solve the problem on a smaller surface >>> with more predictability, less impossible solution to find. >>> I hope so. >>> And if it saves 90% of the time, that s already a win, imho. >>> >>> May i ask another question, >>> have you considered to create the plumbing >>> at runtime rather than statically ? >>> With some intents from the syntax, necessarily >>> (and yeah go 1 compat will be a problem, let s forget it for 1 minute). >>> >>> I suspect in some aspects in might be handier, >>> because it might be all about chained func calls and not type system >>> handling, >>> and it might be easier to interleave the ctx.check in the flaw of ops, >>> I don t know enough to realize for sure. >>> >>> >>> >>> On Wednesday, May 10, 2017 at 11:40:27 PM UTC+2, Sameer Ajmani wrote: >>> >>>> Our approach was to identify function calls that consume a Context >>>> (indicated by a call to context.TODO in the function body) and function >>>> calls that provide a Context (such as RPC and HTTP handlers). Then we use >>>> the guru callgraph tool to find all call paths from context providers to >>>> context consumers. These are the call paths that need to have a context >>>> plumbed through them. >>>> >>>> Starting from a context consumer, we can work upward to the context >>>> provider, adding a context parameter to reach intervening function >>>> signature. Replace context.TODO in the consumer function body with the new >>>> ctx parameter, then update all the places that call the consumer to pass >>>> context.TODO. Now we have a new set of context consumers. Repeat until you >>>> reach the context providers (if you reach main or a Test function, pass >>>> context.Background instead). >>>> >>>> This works OK for static function calls but gets messy for dynamic >>>> calls. If you need to add a context parameter to an interface method, now >>>> you have to update all implementations of that method, too (guru can find >>>> these for you). And if that interface is outside your control (like >>>> io.Writer), you cannot change its signature, so you have to pass the >>>> context some other way (such as via the method receiver). >>>> >>>> This gets yet more complicated if you cannot make atomic changes to all >>>> callers of your functions, because callers may be in other repositories. In >>>> this case, you must do an incremental refactoring in multiple steps: each >>>> change to a function signature involves adding a new function that has the >>>> context parameter, then changing all existing calls to use the new >>>> function, while preventing new calls to the old function, so that you can >>>> finally delete it. >>>> >>>> Inside Google, we ended up not needing to build all this: Context was >>>> introduced early enough that Go users could plumb it manually where needed. >>>> I think a context plumbing tool could still be interesting and useful to >>>> other Go users. I'd love to see someone build it! >>>> >>>> S >>>> >>>> On Tue, May 9, 2017 at 10:54 AM <mhh...@gmail.com> wrote: >>>> >>>>> > I've done a limited form of this using awk ;-) >>>>> >>>>> if you have a minute, >>>>> >>>>> can you tell more about what limited you >>>>> in your attempts and which trade made you stop (guessing), >>>>> if any ? >>>>> >>>>> Do you still think it be awesome ? >>>>> Or have you made your mind to an opposite position ? >>>>> if so, For which reasons? >>>>> >>>>> My tool is very poor, consider it as on going, a place for inspiration >>>>> to get started from absolutely no idea to lets get a dirty prototype. >>>>> not sure yet how long is going to be the road, still digging :) >>>>> >>>>> >>>>> On Tuesday, May 9, 2017 at 4:25:46 PM UTC+2, Sameer Ajmani wrote: >>>>> >>>>>> The eg tool can execute simple refactoring steps, but automating >>>>>> context plumbing through a chain of calls is an open problem. Alan >>>>>> Donovan >>>>>> put some thought into this a few years ago, and I've done a limited form >>>>>> of >>>>>> this using awk ;-) >>>>>> >>>>> On Tue, May 9, 2017 at 6:10 AM <mhh...@gmail.com> wrote: >>>>>> >>>>> I want something similar too. >>>>>>> >>>>>>> Automatic and smart insertion of context args in a chain of calls. >>>>>>> >>>>>>> Methods signature updates are easy, but how to appropriately insert >>>>>>> context check in the ast ? >>>>>>> I m not sure yet. >>>>>>> >>>>>>> >>>>>>> >The difficulty here seems to differentiate intra package calls from >>>>>>> calls to standard/3rd party libraries which shouldn't be having new >>>>>>> param. >>>>>>> >>>>>>> That does not sound too difficult, from the pkg identifier, lookup >>>>>>> for the import path, for every import path, exists in GOROOT ? >>>>>>> >>>>>>> Please put updates here anything you want to share. >>>>>>> >>>>>>> At that moment i m using this package to help me with ast, >>>>>>> https://github.com/mh-cbon/astutil >>>>>>> >>>>>>> might be a start even though it needs refactoring. >>>>>>> >>>>>>> >>>>>>> On Monday, May 8, 2017 at 1:03:52 AM UTC+2, meir fischer wrote: >>>>>>>> >>>>>>>> I'm adding tracing to an existing code base with many packages and >>>>>>>> it seems the best way to have context's passed around is to just have >>>>>>>> every >>>>>>>> method take a context.Context. >>>>>>>> >>>>>>>> Is there any tooling for converting a code base/package to have: >>>>>>>> (a) context.Context as the first parameter in each function - ctx >>>>>>>> context.Context >>>>>>>> (b) for any function that has changed, have its callers (within >>>>>>>> that package) pass ctx as the first arg >>>>>>>> >>>>>>>> The difficulty here seems to differentiate intra package calls from >>>>>>>> calls to standard/3rd party libraries which shouldn't be having new >>>>>>>> param. >>>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "golang-nuts" group. >>>>>>> >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to golang-nuts...@googlegroups.com. >>>>>> >>>>>> >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "golang-nuts" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to golang-nuts...@googlegroups.com. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to golang-nuts...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
