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 <javascript:>> 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 <javascript:>. >> 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.
