I was about to make a PR but saw in the tests that context is already being used as a closure and since I've been both wrong and do not have a convincing reasoning for this change, it seems things are working fine.
On Monday, February 27, 2017 at 5:59:55 PM UTC+3:30, dc0d wrote: > > 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.
