According to the docs "Wait blocks until all function calls from the Go method have returned, then returns the first non-nil error (if any) from them"; it doesn't say if I cancel the original context what will happen.
The parent/child pattern for using contexts (a hierarchy of contexts) is not applied here - so the children would not get notified that things got canceled - and if I need to check the "<-Context.Done()" I have to pass it as a closure (or somehow) to the functions in the group. It would be nice if there was "func (g *Group) Go(f func(context.Context) error)" instead of "func (g *Group) Go(f func() error)". On Monday, February 27, 2017 at 4:56:27 PM UTC+3:30, Ian Davis wrote: > > > On Mon, 27 Feb 2017, at 11:39 AM, dc0d wrote: > > Is there any drawbacks if we put the CancelFunc of a cancellable > context.Context inside it's values? > > Problem: I needed a cross breed of WaitGroup and Context. So a WaitGroup > and it's CancelFunc is put inside it's values and are used with some helper > functions. I wrote a variant of WaitGroup - with some needed features - but > I see this pattern of accepting an argument like "ctx context.Context" as > the first argument in functions. So I though it might be more idiomatic to > use the Context instead. Any thoughts/suggestions? > > > Have a look at https://godoc.org/github.com/golang/sync/errgroup which > seems to cover your use case > > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
