[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-lambda-dev
Subject:    PipelineHelper and ParallelPipelineHelper
From:       paul.sandoz () oracle ! com (Paul Sandoz)
Date:       2012-09-24 19:16:55
Message-ID: 21704C1A-C5AA-4F92-A443-0C5389316C02 () oracle ! com
[Download RAW message or body]

Hi

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

  http://cr.openjdk.java.net/~psandoz/lambda/ophelper/webrev/

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);

    @Override
    <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.

Paul.


[prev in list] [next in list] [prev in thread] [next in thread]