PipelineHelper and ParallelPipelineHelper

Paul Sandoz paul.sandoz at oracle.com
Mon Sep 24 12:16:55 PDT 2012


Here is a rough start refactoring to introduce a PipelineHelper for the serial case and a corresponding ParallelPipelineHelper for the parallel case:


Needs more work before committing.

All the tests pass.

Part of the reason for this is to clean up TerminalOp and ShortCircuitTerminalOp. For serial evaluation the latter should always pull (even if a sink is used) while the former could pull/push depending on whether there is a intermediate short-circuiting op, or the stream has already been pulled from before evaluation, or because it is implementation chooses to pull rather than push.

I am not sure i have the methods on PipelineHelper/ParallelPipelineHelper quite sorted out just yet. 

In the parallel case ParallelPipelineHelper is most often used as follows: 

  spliterator.into(helper.wrapSink(reduceStage)); // non-short circuiting
  helper.wrapIterator(spliterator.iterator()) // short-circuiting

So currently the only relationship between ParallelPipelineHelper and PipelineHelper is the requirement for parallel evaluation to defer to serial evaluation when there is no implementation for the former. Hence the inheritance relationship:

    RES evaluate(PipelineHelper<E_RES> helper);

    <E_SRC> RES evaluateParallel(ParallelPipelineHelper<E_SRC, E_RES> helper) default {
        System.out.println(getClass().getSimpleName() + " using TerminalOp.computeParallel serial default");
        return evaluate(helper);

I also tried to make clearer the definition of the type variables.


More information about the lambda-dev mailing list