A priori I do not believe the claim made here: a GPars task is
submitted
to a thread pool, which is exactly what the goroutines are.
Thus the
number of Java threads is not a bound on the number of GPars
tasks. Any
bounds will be provided by the Fork/Join pool.
Here is a GPars sample from
http://www.gpars.org/1.0.0/guide/guide/GroovyCSP.html
final class Copy implements Callable {
private final DataflowChannel inChannel
private final DataflowChannel outChannel1
private final DataflowChannel outChannel2
public def call() {
final PGroup group = Dataflow.retrieveCurrentDFPGroup()
while (true) {
def i = inChannel.val
group.task {
outChannel1 << i
outChannel2 << i
}.join()
}
}
If inChannel.val blocks, the thread serving the Copy instance is
blocked and lost for serving other channels. If this happens
several times the JVM has run out of threads and the application
is in limbo.
This is not the case in Go. When a goroutine is blocked by a
blocking take on an empty channel, the Go scheduler withdraws the
thread serving this goroutine and assigns it to some other
goroutine.
