FYI, I just started writing a drop in replacement for Context that supports waiting on child contexts. I literally just submitted de initial code and did not test anything seriously yet, but this can help you find your with some ideas of how to proceed:
http://github.com/brunoga/context On Wed, Nov 8, 2017, 5:04 PM Ian Lance Taylor <i...@golang.org> wrote: > On Wed, Nov 8, 2017 at 4:18 PM, Albert Tedja <nicho.te...@gmail.com> > wrote: > > > > I am writing a library that could use the benefit of context, but I also > > want to add additional functionalities to the context my library using, > > while keeping the same golang idiom of using With*() to create a new > context > > based off its parent. > > > > At first, it seems that all I need to do is to satisfy the > context.Context > > interface, but as I look deeper into the context.go source code > > (https://golang.org/src/context/context.go), it looks like that I > wouldn't > > be able to benefit from parent's context, unless I reimplement some of > the > > original context.Context features, in particular its cancelCtx. > > > > For example, the code WithDeadline() creates a context with a deadline, > > which is really just a timerCtx, whose parent is cancelCtx. The context > > package also has this function called "propagateCancel()" which worries > me a > > bit as it looks like the parent context maintains a list of its children. > > > > So, if I want to create a new context with an additional feature, let's > say > > WithFeatureX(context.Context, X), I cannot safely create a FeatureContext > > struct that can inherit from any previous contexts (possibly created from > > WithDeadline/WithCancel/WithTimeout) unless I also do the same thing as > what > > propagateCancel() is doing. The parent context wouldn't know about the > > existence of FeatureContext unless I also duplicate the propagateCancel > to > > include itself as a child. In other words, the relationship between the > > parent context and its children is hard-coded in the context package. > > > > My goal is to allow users of my library to specify their own context, > either > > from Background() if they want just the basic, or WithTimeout() or > > WithCancel(), and then pass their context to library's own custom > contexts > > WithFeatureX() or WithFeatureY() to add additional features, yet still > > retain its original parent's ability, whatever it is. It seems to me > this is > > not possible without a lot of work and possibly access to the context > > package private functions. > > > > Could you guys please let me know if my analysis is correct that > > context.Context is not really designed for this purpose? Or am I just > simply > > wrong and overlooking something obvious? > > Can you just have a field of your Context type be a value of type > context.Context? > > Ian > > -- > 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.
