"find" operation on parallel iterators? about rayon

[cuviper]

You could do position just fine for any ExactParallelIterator, just like enumerate does.
(edit: that's actually the tighter IndexedParallelIterator)

[nikomatsakis]

Probably to be most useful position would return any matching position, not necessarily the first one. (Same with find.)

[cuviper]

I made an off-hand comment elsewhere that should probably go here: https://github.com/nikomatsakis/rayon/issues/94#issuecomment-246458377

I've also been thinking about short-circuiting ops like find, any, etc., and these also don't fit well in the current Consumer model. Maybe there's a better push-pull balance we could find here.

@nikomatsakis replied:

I have assumed that short-circuiting ops would use a shared Arc to signal when they should stop (and it'd be somewhat undefined which one you get, of course).

I agree that it should be non-deterministic.

But my point about short-circuiting is that I don't see how to do that in a meaningful way. Yes, you could use AtomicBool to skip to comparison of find itself, but this is at the tail-end of the Consumer chain. The rest of the parallel iterator is going to continue pushing items down to this consumer, skip, skip, skip, skip, skip...

What I'd like is some method of feedback for a consumer to say, "I'm done here, don't feed me anymore!" A normal Iterator gets this naturally since it's a pull model -- they just don't call next() anymore. It doesn't have to be perfect cessation here, so some extra items could still trickle down, but there should be a best effort mechanism.

Perhaps they could return an Option from splits, and/or from the conversions into_folder. That would allow a chance to return None and completely avoid whole chunks of iteration.

[nikomatsakis]

@cuviper

Yes, you could use AtomicBool to skip to comparison of find itself, but this is at the tail-end of the Consumer chain. The rest of the parallel iterator is going to continue pushing items down to this consumer, skip, skip, skip, skip, skip...

Hmm. I see. It seems like we could add some sort of callback to the consumer traits for this readily enough.

I will add this issue to the 1.0 milestone -- I think we should address this before calling rayon's traits stable in any sense.

[cuviper]

We do have find_any and position_any now, from #129.