Go-like WaitGroup to wait multiple coroutines to finish

Hi, This is more a question than an issue, however - are there any plans to have WaitGroup-like mechanism? Go documentation for WaitGroup is here.

The problem it is supposed to solve is how to wait bunch of coroutines to complete? Here is a nice summary. Currently it is achievable via channels (sort of done channel) or just by doing jobs.forEach { it.join() }. However the latter requires extra list / array allocation whilst WaitGroup is effectively an atomic counter wrapper with some wait logic in it (see examples). Although it can be implemented quickly it still might be useful as a part of kotlinx.coroutines.

[elizarov]

I do not immediately see how WaitGroup makes the code cleaner. Compare an example with WaitGroup to an example with a list of jobs. This is a line-by-line translation:

fun test() = publish(CommonPool) {
    val output = Channel<String>()
    val jobs = mutableListOf<Job>() // replaces waitGroup

    // start coroutine per thing
    listOfThings.consumeEach {
        jobs += launch(context) { // replaces waitGroup.add(), no need for waitGroup.done() 
            doSomething(it, output)
        }
    }

    launch(context) {
        for (t in output) {
            send(t)
        }
    }

    // wait for all the coroutines to finish
   jobs.forEach { it.await() } // replaces waitGroup.wait() 
}

It looks cleaner and less error-prone without WaitGroup. In particular, the example with a WaitGroup has a subtle bug that would reproduce only rarely (heisenbug). Under certain load, the first waitGroup.add() could be immediately followed by an invocation waitGroup.done(), thus triggering WaitGroup’s notification prematurely. There is no risk of making this mistake with a list of jobs.

Please, keep in mind that in Go there is nothing like a Job, so there is simply no other way to wait for a group of coroutines to finish. Go has to have something like WaitGroup with all its error-proneness. But we don’t have to.

Also note, that in kotlinx.corotoines the Job is already created with each coroutine you launch. Allocating an array to keep their list is a relatively minor constant-fraction overhead to that.

[alek-sys]

Thanks for clarification, it makes sense. Good point about not having Job class in Go!