Hey @ZHOUYue67!

Sorry for the delay, I've been busy the last weeks.

Yes, your usage in v2 is correct if you need to immediately cancel all running tasks when any of the tasks returns an error.
In v2 there's still a "child context" being created under the hoods which extends the passed context and is cancelled when any of the tasks in the group return a non nil error (or panic), but it's just not being returned explicitly to the caller anymore. I think this is preventing use cases like the one you mention. It would be nice to have a way to expose that context so it can be referenced by all tasks to cancel in-flight operations when the first error occurs, I think I ignored this use case when coming up with the new design for v2.

I'm thinking the group object could expose the underlying context via a Context() method (to keep it consistent with the pool's Context() method). Having this, the code you provided could be rewritten as follows:

pool := pond.NewPool(10)
defer pool.StopAndWait()
group := pool.NewGroupContext(parentCtx) // use parentCtx or ctx here is about the same
group.SubmitErr(func() error{
  err := doSomethingComplex(group.Context())
  return err 
})
group.SubmitErr(func() error{
  err := doSomethingElseComplex(group.Context())
  return err
})
if err := group.Wait(); err != nil {
  // No need to explicitly cancel the context
  // continue to handle error 
}

I don't want to return this context when creating the group (as it was in v1) because that breaks retro-compatibility and prevents chaining method calls in a single line.

What do you think about this change?

Thanks for brining this up 🙂