| 126 |
|
* op.apply(array[lo]); |
| 127 |
|
* tryComplete(); |
| 128 |
|
* } |
| 129 |
< |
* } }</pre> |
| 129 |
> |
* }}</pre> |
| 130 |
|
* |
| 131 |
|
* This design can be improved by noticing that in the recursive case, |
| 132 |
|
* the task has nothing to do after forking its right task, so can |
| 133 |
|
* directly invoke its left task before returning. (This is an analog |
| 134 |
|
* of tail recursion removal.) Also, because the task returns upon |
| 135 |
|
* executing its left task (rather than falling through to invoke |
| 136 |
< |
* tryComplete) the pending count is set to one: |
| 136 |
> |
* {@code tryComplete}) the pending count is set to one: |
| 137 |
|
* |
| 138 |
|
* <pre> {@code |
| 139 |
|
* class ForEach<E> ... |
| 291 |
|
* return new MapReducer<E>(null, array, mapper, reducer, |
| 292 |
|
* 0, array.length).invoke(); |
| 293 |
|
* } |
| 294 |
< |
* } }</pre> |
| 294 |
> |
* }}</pre> |
| 295 |
|
* |
| 296 |
|
* Here, method {@code onCompletion} takes a form common to many |
| 297 |
|
* completion designs that combine results. This callback-style method |
