Non interference enforcement

[Doug Lea]

On 09/26/12 09:26, Remi Forax wrote:
> We currently ask users to write lambdas that doesn't interfere with the source
> collection
> of a stream but it's not enforced in the code.
>
> By example,
>    list.stream().forEach(e -> { list.remove(e); });
> may works or not depending how the pipeline is implemented.
>
> This is a serous departure for the current way java.util collections works
> and I wonder if we should not keep the fail-fast guarantee for those collections.
>

Relatedly: The soon (I hope) forthcoming StampedLock will make
efficient read-write-locked collections etc easier to build.

Background: There is nothing you can do to fully automate such
things because you don't know for sure whether methods on an
arbitrary collection that "should" be read-only actually are.
But for those that do/will exist, iterators are still a big
problem since you cannot implement as:
   readLock; process elements; unlock
(or partially optimistic variants).
Instead, these must do some expense stuff on each iteration,
and either fail or do some even more expensive stuff on
interference.

So, at least for the StampedLock-based Vector work-alike class
that will be in j.u.c preview (and may be releasable in j.u.c),
I include:
   void forEachReadOnly(Block<T> action)
That will be much cheaper wrt sync, and hopefully not
negated by megamorphism etc.

It would *almost* be a good idea to default to using
this for any Stream tie-ins, but it seems impossible
to read people's minds about intent here. So for now
I leave this issue as a future possibility.

-Doug