proposal: sync: add WaitGroup.Notify to use with select

[mohamedattahri]

Background

Integrating WaitGroup with select statements, especially in context-aware operations where cancellation might be necessary, requires creating an additional channel for signaling.

Proposal

I propose extending sync.WaitGroup with a new method:

func (wg *WaitGroup) Notify() <- chan struct{}

This method would return a channel that is closed when WaitGroup.Wait returns.

Example

Instead of:

c := make(chan struct{})
go func() {
    wg.Wait()
    close(c)
}()

select {
case <-ctx.Done():
    return context.Cause(ctx)
case <-c:
    return nil
}

You could do:

select {
case <- ctx.Done():
    return context.Cause(ctx)
case <- wg.Notify():
    return nil
}

Conclusion

This boilerplate it replaces is small, but I believe it does a lot to bring WaitGroup closer to the built-in concurrency tools offered by the language.

CC #71076.

[gabyhelp]

Related Issues

• proposal: sync: add WaitContext to WaitGroup #40916
• sync: Add a method to WaitGroup to simplify Add, Done, go func() #44473 (closed)
• proposal: sync: add WaitGroup.Go method #39863 (closed)
• proposal: sync: add Go method to WaitGroup to launch a tracked goroutine #63796
• sync: Proposal: Add a Go() function to sync.WaitGroup #23538 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[zigo101]

See: https://pkg.go.dev/go101.org/nstd#WaitGroup.WaitChannel

[zephyrtronium]

I think this is a strictly worse version of what x/sync/errgroup does. #40916 (comment) is exactly my sentiment:

In most cases when you have the possibility of a timeout, you want to cancel the work rather than just the action of waiting on the work, and you want to distinguish between “work completed” (err != nil) and “work timed out” (err == nil). For those cases, errgroup.WithContext is usually a better fit.

[zigo101]

This is a very basic package, don't let Context pollute it.

[krishpranav]

Hi, so do you want to implement the new functionality?

[mohamedattahri]

@zephyrtronium - I wouldn't compare them one to one.

I agree that errgroup offers a much better way to handle context cancellation, but there are many cases where a WaitGroup is one of many concurrent things you're managing.

In my view, this makes compatibility with the select statement a desirable feature.

I'd even argue that errgroup.Group should feature an analog method — with a channel that returns an error of course.

@zigo101 — There is no context involved here.

[zigo101]

I mean errgroup.WithContext introduces Context.