You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
sync.WaitGroup offers a flexible way to wait for an arbitrary number of tasks submitted. In golang.org/x/sync/errgroup we see a neat method called Go(func() error) that spawns a goroutine and makes sure that the internal counters are adjusted appropriately. Would this be a useful addition to sync.WaitGroup as well? Essentially it'd be used like this:
Internally the implementation would be very simple:
// Go calls the given function in a goroutine and adds it to the WaitGroup.func (wg*WaitGroup) Go(ffunc()) {
wg.Add(1)
gofunc() {
deferwg.Done()
f()
}()
}
A fair argument against this would be "just use errgroup", which feels incredibly useful whenever you fan out to multiple goroutines and wait for their result, especially as it deals with cancellation properly. Is there maybe a possibility to put that library into core Go instead?
This was mostly spawned by a code review where a reviewer take issue with the use of an errgroup with no error involved, as all errors were supposed to be ignored, and hence suggesting the use of sync.WaitGroup instead.
The text was updated successfully, but these errors were encountered:
sync.WaitGroup
offers a flexible way to wait for an arbitrary number of tasks submitted. Ingolang.org/x/sync/errgroup
we see a neat method calledGo(func() error)
that spawns a goroutine and makes sure that the internal counters are adjusted appropriately. Would this be a useful addition tosync.WaitGroup
as well? Essentially it'd be used like this:Internally the implementation would be very simple:
A fair argument against this would be "just use errgroup", which feels incredibly useful whenever you fan out to multiple goroutines and wait for their result, especially as it deals with cancellation properly. Is there maybe a possibility to put that library into core Go instead?
This was mostly spawned by a code review where a reviewer take issue with the use of an errgroup with no error involved, as all errors were supposed to be ignored, and hence suggesting the use of
sync.WaitGroup
instead.The text was updated successfully, but these errors were encountered: